CSTS Service Instance Identification Summary of CSTS Discussions on M.Götzelmann

CSTS Issue1 – Structure of Service Instance IDs SLE Service Books & CSTS Specification Framework specify sagr=.spack=. =. =. := rsl-fg | fsl-fg := raf | rcf | rocf | cltu | fsp := onlt | onlc | offl | cltu | fsp Agencies have defined their own conventions –DSN uses a special spacecraft code for sagr –DLR uses the spacecraft mnemonic These conventions find their way into parsers and other SW Identifiers defined according to different conventions cause interoperability problems CCSDS should specify a format to enough detail that such problems can be avoided

CSTS Issue 2: Scheduled vs. Permanent SI (1/2) SLE RM and Service Specifications –SLE requires that each Service Instance is agreed between UM and CM and scheduled in advance –A service Instance has a single uninterrupted provision period during which it can be used –A service instance is provided at a specific location (Facility) and can be accessed via a port identified by a logical port identifier. Initial ad-hoc service management approaches distinguish –Scheduled Service Instances Are defined in a service instance configuration file a specific scheduled session (pass) Identify the facility and pass number in the ID (JPL/ESA agreement) –"Permanent" Service Instances

CSTS Issue 2: Scheduled vs. Permanent SI (2/2) "Permanent" Service Instances –Have no pre-defined provision period ( "permanent") –Are "loaded" at the beginning of a pass and unloaded at the end and that repeats every pass –One can look at this in two ways The provision period extends over many passes but is "suspended" between passes. A new SI is implicitly created every pass with a provision period = pass –Service Instance Identifiers do not identify a pass number and are therefore the same for all passes Use of "permanent service instances" is the preferred approach, but obviously does not fully conform to the standard CCSDS Recommendations should be adapted to match the preferred way of operating

CSTS Permanent SI (1/3) - Objectives Why are "permanent" SI attractive? –The specification of SI is typically the same except for the provision period and the ground station –Providers can store the specification once for a mission and just reference it for every pass –Users want to always use the same identifier and not have to manage new identifier for every pass Objectives for Standard Adaptation –Should keep the concept of service instances Embedded within a session (service package) With a single uninterrupted provision period With specified user, provider, and provide port identifier –Should minimise changes to the Recommendations –Should have to enter all specs except the provision period and port only once –Should be able to use the same identifier in BIND for every pass

CSTS Permanent SI (2/3) - Proposal Specify "Service Instance Templates" for all service instances that might be needed within a service package within the service agreement. In the templates define all parameters except provision period (and possibly logical port ID) When defining a service package "instantiate" the templates adding provision period (and possibly port IDs) for each instantiation. In the BIND invocation identify the template and the ground station instead of the actual service instance same identifier for the SI on the same ground station.

CSTS Permanent SI (3/3) - Example Service Agreement: SI template definitions –RAF1, –RCF1 –RCF2 –MON1 Service Package X: SI definitions –RAF 1 (Tstart, Tstop, Port) –RCF 2 (Tstart, Tstop, Port) –MON 1 ((Tstart, Tstop, Port) User knows RAF1, RCF1, RCF2, MON1. Within the service package X the attempt to bind to SI RCF1 will fail, bind to RCF2 will succeed

CSTS Service Instance Identifier (in BIND) Observation: –IF different Service Agreements may be used for mission phases but not for modes of operation (e.g. safe mode) –THEN: the spacecraft ID uniquely identifies the service agreement in a given context (i.e. for a connection between user and provider) at a given time. –In a given context at a given time the provider facility might be fully identified the service package (to be verified) Proposed Components of the SI ID (in BIND) 1.Spacecraft ID (format: string) The standard says a mnemonic but a number will work if agreed 2.Facility ID (format string) – or service package ID if needed The standard says a mnemonic but a number will work if agreed 3.Service Type (name as defined in the service specification or OID?) 4.Service Instance Number

CSTS RCF 3 Potential Issue RAF1 SI Templates RCF 1 RCF 2 SI RAF1 RCF 1 RCF 2 RCF 3 RCF 2 RAF1 SI Templates RCF 1 SI RAF1 RCF ? Assume RCF1 and RCF 2 have different specs