Cross Support Services Area Functional Resource Identifiers in SCCS-SM Information Entities John Pietras London, UK October 2010

Cross Support Services Area 2 Purpose of Presentation To refine the approach by which functional resource identifiers are explicitly embedded in SCCS-SM information entities –This approach was selected at the Noorwijk meeting –Functional resource identifiers are used for identifying the monitored parameters and notifiable events that are reported by the Monitored Data CSTS (MD-CSTS) –Functional resource identifiers are currently proposed to be used for identifying real-time reconfigurable parameters to be changed via the Service Control CSTS (SC-CSTS) –Other possible uses for functional resource identifiers Service Package reconfigurable parameters (simpler than the Blue- 1 method?) Space Link Events Profile reconfigurable parameters (simpler and more extensible than the Blue-1 method?)

Cross Support Services Area 3 Concept of Functional Resource Functional resources provide naming domains for parameters (monitored and reconfigurable), event notifications, and real-time control actions – : A functional resource is a logical component that performs an atomic function/set of functions related to a Service Package –Multiple instances of a functional resource type can operate concurrently within a single Service Package –Practical notion of functional resource: if two or more instances of “something” can exist concurrently, that “something” should be a separate functional resource type A functional resource type may have associated with it –One or more monitored parameter type names that can be requested to be reported cyclically and/or for which the current value(s) can be requested –One or more event type names for which notification can be requested upon its (their) occurrence –One or more configurable parameters

Cross Support Services Area 4 Strawman Functional Resource Classes Antenna Forward space link Forward space link subcarrier Forward space link symbol stream FCLTU transfer service provider Return space link Return space link subcarrier Return space link symbol stream RAF transfer service provider RCF transfer service provider Multiplexer Access Point (MAP) Channel TC Virtual Channel FSP transfer service provider ROCF transfer service provider Correspond to resources Already addressed by Blue-1 SCCS-SM Beyond Blue-1 SCCS-SM

Cross Support Services Area 5 Production and Provision of MD-CSTS monitored Functional Resource instance MD-CSTS Production MD-CSTS Provision MD-CSTS instance MD-CSTS instance monitored Functional Resource instance monitored Functional Resource instance monitored Functional Resource instance data collection of Service Package monitored parameter measurements and event notifications

Cross Support Services Area 6 Functional Resource Identifiers Must be able to be related to the managed entities that are scheduled/configured via Service Management Must be statically defined (e.g., in a Service Agreement) to satisfy requirements of Monitored Data CSTS Three approaches were presented at Noordwijk meeting 1)Configuration profile XPath name 2)Explicit functional resource identifiers embedded in Service Management information entities 3)Functional resource identifier taxonomy that corresponds to existing SM information entity naming parameters

Cross Support Services Area 7 Approach Selected in Noordwijk In Service Management information entities that correspond to functional resource instances, include a functional resource identifier parameter in an SM data set (class) corresponding to each functional resource Pro –Can result in much shorter names than XPath approach –Easier (than XPath approach) to provide static names –Avoids complexity of deriving names found in Approach 3 Cons –SCCS Service Management must be implemented in order to use MD-CSTS, BUT –Blue-1 SCCS-SM does not support the embedded names Approach 2 was selected for further development, given that work on SCCS-SM Blue-2 has begun –SCCS-SM Blue-2 is the point where MD-CSTS and SC-CSTS will dovetail –Appropriate functional resource IDs can be added to Blue-2 data sets/classes Updated approach: functional resource IDs will be added to Blue-1 data sets/classes and corresponding XML schema types for proof-of-concept and prototyping purposes –Available for use by Blue-1 adopters that need to use the Monitor Data and Service Control CSTSes –Corresponding additions to Blue-2 classes can be determined as the refactoring progresses

Cross Support Services Area 8 Progress(?) in Portsmouth Approach was proposed in which at least one separate Space Link Carrier Agreement would be associated with each real space link carrier functional resource, and functional resource IDs would be assigned to each component of the Carrier Agreement (the carrier itself, subcarrier, and symbol stream(s)) –Monitor and control data parameter type names associated with those SA subclasses would be combined with those functional resource IDs to form the published parameter names –Reference to any Space Link Carrier Agreement in a Service Package (via the xxxSpaceLinkCarrierAgreementRef parameters of the Space Communication Service Profiles referenced by that Service Package) activates the specific monitor/control parameters and associates them with the appropriate resources Approach was rejected in Portsmouth –Some participants confused by functional resource identification in Service Agreement instead of in Configuration Profiles –Required additional constraints on Space Link Carrier Agreements In particular, that at least one Space Link Carrier Agreement exist for each physical space link –Recommendation to rework approach to include functional resource identification in Configuration Profiles

Cross Support Services Area 9 Simplified Overview of Revised Approach Space Communication Service functional resource identifiers Service- Agreement contains Service- Agreement data set Service- Agreement data set Space Communication Service Profile data set references cross support transfer service functional resource identifiers Service- Agreement data set Service- Agreement data set transfer service map references contains

Cross Support Services Area 10 Functional Resource IDs for Space Communication Service Resources in the Service Agreement (1 of 2) Functional resource identifiers for RF, modulation, synchronization, coding and space link protocol processing functional resources are recorded in the Service Agreement –Static nature of identifiers is required to comply with Monitored Data CSTS concepts regarding publication of monitored parameter qualified names (which include functional resource IDs) A functional resource ID list is added to each subclass of the Service Agreement ConfigurationConstraintsSpecification component class that correspond to functional resource types that may have more than one instance operating concurrently in a single service package –CarrierAgreement –SubcarrierAgreement –SymbolStreamAgreement –TransferServiceAgreement –Rationale: if two or more instances of the same parameter may be active during the execution of a Service Package, there must be a unique functionalResourceId to disambiguate the instances

Cross Support Services Area 11 Functional Resource IDs for Space Communication Service Resources in the Service Agreement (2 of 2) In an instantiated Service Agreement, each functional resource ID list is populated with the functional resource IDs that can be used by a Service Package to label the monitor and control parameters associated with that functional resource type –The difference with respect to the previous (Portsmouth) approach is that the functional resource ID list contains (possibly multiple) IDs that may be used for each component of the Service Agreement, not a single ID that must be used for each component of the Service Agreement The combinations of functional resource identifiers for each functional resource type and the monitored/controlled parameter names for each of those functional resource types constitutes the set of published names for those monitored/controlled parameters A Service Agreement subclass that has no functional Resource ID list of its own shares the functional Resource ID list of the class that contains it –E.g., Monitored parameter types associated with production of the RAF service (e.g., numberOfGoodFramesReceived) use the names contained in the symbol stream functional resource ID list

Cross Support Services Area 12 Carrier Agreement Components with Functional Resource ID List Parameters (partial class diagram) Strictly speaking, not necessary for Blue-1, but needed if Blue-2 allows multiple subcarriers

Cross Support Services Area 13 Example (Sub)Set of Published Monitored Parameters Spacecraft XenoSat can support one S-Band forward link, one S-Band return link, and one X-Band return link –In the Service Agreement, each of these links gets its own SpaceLinkCarrierAgreement object with functional resource ID list with one member f401SpaceLinkCarrierAgreementId = “Forward_carrier”; spaceLinkCarrierFrIdList = {“Forward_carrier”} r401SpaceLinkCarrierAgreementId = “Return_S-Band”; spaceLinkCarrierFrIdList = {“Return_S-Band”} r401SpaceLinkCarrierAgreementId = “Return_X-Band”; spaceLinkCarrierFrIdList = {“Return_X-Band”} –Alternatively, the two return links might “share” the same SpaceLinkCarrierAgreement object, in which case the functional resource ID lists would look like f401SpaceLinkCarrierAgreementId = “Forward_carrier”; spaceLinkCarrierFrIdList = {“Forward_carrier”} r401SpaceLinkCarrierAgreementId = “Return_carrier”; spaceLinkCarrierFrIdList = {“Return_S-Band”, Return_X-Band”} The monitored parameter types for a forward carrier include actualTransmitFrequency The monitored parameter types for a return carrier include actualReceiveFrequency The corresponding published names for the resulting monitored parameters are –“Forward_carrier:actualTransmitFrequency –Return_S-Band:actualReceiveFrequency –Return_X-Band:actualReceiveFrequency NOTE The syntax of the following functional resource identifiers is for purposes of constructing the examples only

Cross Support Services Area 14 Functional Resource References for Space Communication Service Resources in Space Communication Service Profiles For each Space Communication Service Profile subclass that corresponds to a Service Agreement subclass that contains a functional resource ID list, that Space Communication Service Profile subclass contains a functionalResourceRef parameter For each instantiated Space Communication Service Profile, each functionalResourceRef parameter is populated by a functionalResourceId value from the functional resource ID list of the corresponding Service Agreement object Inclusion of a functionalResourceId value in a Space Communication Service Profile object specifies which subset of functional resource IDs (and therefore which set of qualified monitored/control parameter names) apply to the resources configured according to that SCSP object

Cross Support Services Area 15 Space Communication Service Profile Components with Functional Resource Reference Parameters (partial class diagram)

Cross Support Services Area 16 Examples of Functional Resource References in Space Communication Service Profiles Continue with the previous XenoSat example, with separate Space Link Carrier Agreement objects for each of the 3 carriers The data on the return links is modulated onto the subcarrier of each. Functional resource IDs for the return subcarriers are: –For r401SpaceLinkCarrierAgreementId = “Return_S-Band”; subcarrierFrIdList = {“Return_S-Band.sub”} –For r401SpaceLinkCarrierAgreementId = “Return_X-Band”; subcarrierFrIdList = {“Return_X-Band.sub”} The monitored parameters for the return subcarrier include subcarrierLockStatus The corresponding published names for the resulting monitored parameters are –Return_S-Band.sub:subcarrierLockStatus –Return_X-Band.sub:subcarrierLockStatus

Cross Support Services Area 17 Issue: Semantic Enforcement In the previous example, CM can enforce that the Return_S-Band.sub subcarrierFrIdList value be used only in the context of the Return_S-Band R401SpaceLinkCarrierAgreement (and the same for return X-Band) because each functional resource ID list has only one member However, in the alternative case (see slide 14), one R401SpaceLinkCarrierAgreement has a functional resource ID list with two members. CM has no way of enforcing the semantic correctness of the FR ID that is used in the R401SpaceLinkCarrierProfile; e.g., the specified spaceLinkCarrierFrIdList value could be “Return_S-Band” but the value of spaceLinkCarrierFrIdList of the contained R401Subcarrier object could be “Return_S-Band.sub” –The only enforceable constraint is that each ID must be used uniquely across the Space Communication Service Profiles referenced by a Service Package Commentary –In this approach, the functional resource IDs are really just labels that the Service Package “tells” CM to apply to the monitor/control parameters associated with the resources that are allocated to the components (carriers, subcarriers, symbol streams) of the Space Communication Services of the Service Package –“S-Band” and “X-Band” could just as easily be called “Carrier 1” and “Carrier 2” Possible solutions/resolutions –“Don’t care”: Let them continue to be treated as mere labels. UM is responsible for applying them in an operationally-useful way Won’t work if CM requires “hard-coding” of functional resource IDs to real resources –Return to Portsmouth approach of aligning Space Link Carrier Agreements with specific real space link carriers –Hybrid approach: In general, SM doesn’t care, but individual Complexes may require that Space Link Carrier Agreements be associated with specific real space link carriers (i.e., that the FR ID list contain only one ID) –Use of relative distinguished names for construction of functional resource IDs

Cross Support Services Area 18 Relative Distinguished Names for Functional Resource IDs (1 of 2) Similar to the approach already outlined, but instead of the full functional resource ID being named for every, only the relative distinguished names (RDNs - i.e., name subfields) for those components are included in the functional resource ID lists and used in the functional resource references –Service Agreement Space link carrier functional resource RDN list Subcarrier functional resource RDN list Symbol stream functional resource RDN list –Space Communication Service Profile Space link carrier functional resource relative distinguished reference (RDR) Subcarrier functional resource RDR Symbol stream functional resource RDR For the XenoSat example, the RDNs for the space link carrier functional resources remain the same –f401SpaceLinkCarrierAgreementId = “Forward_carrier”; spaceLinkCarrierFrRdnList = {“Forward_carrier”} –r401SpaceLinkCarrierAgreementId = “Return_S-Band”; spaceLinkCarrierFrRdnList = {“Return_S-Band”} –r401SpaceLinkCarrierAgreementId = “Return_X-Band”; spaceLinkCarrierFrRdnList = {“Return_X-Band”} but there is only one RDN for the return subcarriers, regardless of which carrier is being used –For r401SpaceLinkCarrierAgreementId = “Return_S-Band”; subcarrierFrRdnList = {“sub”} –For r401SpaceLinkCarrierAgreementId = “Return_X-Band”; subcarrierFrRdnList = {“sub”}

Cross Support Services Area 19 Relative Distinguished Names for Functional Resource IDs (2 of 2) In the Space Communication Service Profile, the RDRs for the space link carrier functional resources remain the same –For spaceLinkCarrierAgreementId = “Return_S-Band”; spaceLinkCarrierFrRdr = {“Return_S-Band”} –For spaceLinkCarrierAgreementId = “Return_X-Band”; spaceLinkCarrierFrRdr = {“Return_X-Band”} but there is again only one RDR for the return subcarriers –For the subcarrier profile contained by the Return_S-Band space link carrier profile, subcarrierFrRdr = {“sub”} –For the subcarrier profile contained by the Return_X-Band space link carrier profile, subcarrierFrRdr = {“sub”} CM concatenates the RDRs to determine the functional resource ID to use –For the subcarrier profile contained by the Return_S-Band space link carrier profile, the functional resource ID = spaceLinkCarrierFrRdr + “.” + subcarrierFrRdr = “Return_S-Band.sub” –For the subcarrier profile contained by the Return_X-Band space link carrier profile, the functional resource ID = “Return_X-Band.sub” Construction in this way cannot result in semantically-inconsistent functional resource IDs

Cross Support Services Area 20 Functional Resource IDs for Transfer Service Resources Each transfer service instance corresponds to a separate functional resource Each transfer service instance is uniquely identified in the context of a Service Package by its service type name (RAF, FCLTU, etc.), its mode (if applicable), and its transfer service instance number –Inclusion of mode is for semantic compatibility with Service Name Identifiers for SLE transfer service instance identification Transfer service functional resource identifiers can be synthesized from service type name plus maxInstancesOfTsType for each service type –E.g., if up to five instances of RAF service can exist, then transfer service functional resource IDs “RAF.1”, …”RAF.5” are possible for the RAF service instances –Actual availability of monitored data for these resource names depends on which ones are actually included in a Service Package –Question – In SLE usage, is the service instance number unique to the service type or the service type and mode? E.g., are “raf=onlc1” and raf=onlt1” possibly, or must the service instance number be unique for each RAF instance regardless of the mode?

Cross Support Services Area 21 Use in Real-Time Service Control CSTS The same functional resource identification scheme can be used to create qualified names of reconfigurable parameters and real-time control actions for the Service Control CSTS Ability to support reconfigurability of any given parameter and/or ability to perform a real-time control action may be Complex- and/or Mission specific, so capability sets will be published in mutually-agreed sets of reconfigurable parameters and control actions

Cross Support Services Area 22 Production and Provision of SC-CSTS controllable Functional Resource instance SC-CSTS Production SC-CSTS Provision SC-CSTS instance controllable Functional Resource instance controllable Functional Resource instance controllable Functional Resource instance Control distribution of Service Package reconfigurable parameter values and control actions

Cross Support Services Area 23 Use for Service Package Reconfigurable Parameters? The syntax is more compact than XPath, which is the current XML mapping technique specified for reconfigurable parameters satisfies the abstract “distinguished name” criterion for reconfigurable parameters Should SMWG consider replacing use of XPath expressions for reconfigurable parameters?

Cross Support Services Area 24 Use for Space Link Events Profiles? Can the syntax provide a simpler and/or more-general approach to naming the parameters that are reconfigured via Space Link Events Profiles?