[Smwg] RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

[John Pietras]

Erik,
I'm not sure what you are asking for n the way of a diagram. Do you just want to see a graphical representation of the contents of the exist CSTS SII vs. the proposed one? Somehow I'm guessing that it's more than that. If you can give me a little better idea of what "situation" you are referring to, I'll give it a stab.

Meanwhile, I'll try to respond to your questions and comments on point 2 (interleaved in <JVP> red </JVP> below). Maybe the answers will be good enough to bypass the need for a diagram (or further clarify what the focus of the diagram should be).

Best regards,
John


From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Thursday, June 04, 2015 8:02 PM
To: John Pietras; CCSDS SMWG ML (smwg at mailman.ccsds.org); CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

John,

Now that I've had a bit of time to digest this, some comments, questions.


1)      Pg 6, it will probably be helpful if a diagram could be produced that illustrates the situation. I hope that is not a significant undertaking.

2)      Assuming that the FRIN being used in the SII is as I think it is (the diagram will help), it does raise some potential concerns

a.       If we assume that the next generation service package has the current B-1 capability (which I believe is the case per the current abstract service request engineering under way) to modify a configuration profile (technically profile re-specification) for the duration of the service package, then do we assume that the addition of a CSTS instance as part of that modification for the service package will come with a "pre-validated" FRIN --> SII ?  Or am I missing something here? ("Turning off" as CSTS instance does not seem like a problem).  Also, we would probably disallow modification of FRINs as part of the service package configuration profile re-specification?



<JVP> Good question and observation. If you recall, in SCCS-SM B-1 we didn't actually allow space communication service profiles to be re-specified in Service Packages to add  (SLE) transfer service instances in an unconstrained way. Rather, each space communication service profile is defined as having an existing set of transfer service mapping objects (TsMaps), where each TsMap is linked to a Transfer Service instance that is defined in a different part of the Service Package. Each TsMap object has an instanceEnabled parameter that is used to include that TS instance in the Service Package. So the greatest possible population of TS instances available via a given space communication service profile *is* predefined - the only option is to re-specify one or more of the  TsMaps as being disabled (i.e., not used in this particular Service Package).



We can use an approach that is similar for Extensible SCCS-SM, although there are possibilities for variations that might be better and should be explored. For the sake of discussion, the approach that is arguably closest to the B-1 approach  is one in which there are a predefined pool of TS profiles (now CSTSes in addition to SLE TSes) that can be used to construct Service Packages. Each of those pre-defined TS profiles will be for a specific service instance and  will have a FRIN that cannot be changed. Each space communication service packages will contain mappings to the maximum set of TS instances that might possibly be used.



This is my current thinking, and I think that it is feasible. If anyone can see flaws of has a better or more elegant approach, please don't hesitate to speak up.



Note that there is a slight difference between this Extensible approach and the B-1 approach. In B-1, we allowed for the possibility of multiple instances of the same TS profile to exist. Multiple TsMap objects is a space communication service profile could point to the same TS profile, and in scheduling a Service Package with such a space communication service profile, Complex Management (CM) would dynamically assign a different transferServiceInstanceNumber to each TS instance. If you think about it, that is exactly the situation that we had when we assumed that CM (now Provision Management (PM)) would dynamically assign the FRINs - Mission users of the service could only know what service instance they were dealing with after reading the Service Package Result. Requiring the there be a profile for each possible TS instance removes that dynamic uncertainty at the cost of creating multiple TS profiles where possibly only one might have needed to be created, although in reality I have come to question whether multiple instances of the same TS profile was all that useful a "feature" anyway.

</JVP>





b.      It seems that for this approach, for things like MD-CSTS or TD-CSTS instances would have to be part of the service configuration profile.   I'm not sure we have agreement that this would be the case - I think we have asked questions like "are things like MD-CSTS just assumed to be there or do they need to be explicitly defined in the service configuration profile"?  I will agree that it does not seem like a likely use case to have two MD-CSTS (or TD-CSTS) instances running in parallel, but I would not put it past an implementation to think of "interesting" deployment options.   Again, perhaps I'm mission something here.



<JVP> I'm not sure that I agree about the unlikelihood of multiple instances of MD-CSTS or TD-CSTS in the same Service Package - for complex spacecraft with concurrent links in multiple bands, there may be operators monitoring performance per band, and as far as TD-CSTS goes, I can easily see the spacecraft control center getting a subset of tracking data that helps them evaluate the progress of a maneuver in near-real time, whereas another TD-CSTS user of the same Service Package might be a Flight Dynamics facility that's collecting all sorts of measurements in order to maintain a highly accurate trajectory model.



Be that as it may, for whatever reasons, I have been assuming that multiple MD-CSTS and TD-CSTS instances can exist in a Service Package (however, I do believe that only one Service Control CSTS instance should exist per Service Package). However, the MD-CSTS and TD-CSTS cases relate to the sService Package in different ways. Let's look at each case individually.



The  MD-CSTS inherently can touch all functional resources in a service package, although the user of the MD-CSTS has to select (using the list-of-parameters and list-of-events parameters of the relevant START invocations) which parameters and event notification will actually be reported. The MD-CSTS has the great advantage that it names its parameters and events using the same functional resource-based naming that Service Management uses. E.g., since the functional resource that corresponds to the X-band downlink is represented in the Service Package as [FR Type OID = {Return 401 Space Link Carrier Reception} : FRIN = 2 ] , when MD-CSTS reports the actual-receive-frequency for [FR Type OID = {Return 401 Space Link Carrier Reception} : FRIN = 2 ] the MD-CSTS user already knows where its coming from.



There may be multiple MD-CSTS profiles (again, one for each possible MD-CSTS instance), but they will "attach" to the service package at a different place than where the space communication service profiles and what I'll call space communication transfer services profiles attach.



Now let's look at the situation with TD-CSTS, which  is a bit trickier. A TD-CSTS instance  is also nominally capable of reporting all tracking data measurements generated out of a service package, so it too attaches to the service package independent of individual space communication service profiles. But the relationship between what tracking-data-generating resources are contained in the configuration profiles and what gets reported in the payload of the TD-CSTS TRANSFER-DATA messages is not as straightforward is it is with MD-CSTS, because the TD-CSTS carries TDM segments that of course contain no reference to functional resource instances. I am still far from coming up with a complete solution, but as of now I'm assuming that the solution will involve something like the following:

1.       Those functional resources that represent resources that generate tracking data will have managed parameters that identify the TDM keyword values that are to be used for those tracking data parameters and associated metadata keywords. Admittedly, this mapping will be complicated, because of the way the TDMs separate their information between metadata and data sections.

2.       The TD-CSTS profiles will have to have some way of specifying which tracking data measurements from which particular functional resource instances are going to be reported by the particular TD-CSTS instance. Unlike MD-CSTS, where the user of the service instance selects what she wants reported dynamically after the service instance is bound, in TD-CSTS all such selections have been deferred to Service Management. I have to admit that that was done so that a TD-CSTS spec could be created without having to develop a language for dynamically specifying what is to be delivered. Yeah - I kicked the can over the wall to Service Management.

So the bottom line is that I'm comfortable that we've got a good handle on MD-CSTS (although I may not have yet convinced you of that), but I admit that there's still a lot of work integrating TD-CSTS into Service Management. But even so, to get back to what I think was the scope of your original question, TD-CSTS will still be an entity of the Service Package as a whole and not "contained by" space communication service profiles.

Did that in any way answer any of your questions?
</JVP>

Best regards,
-Erik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150608/25daeeab/attachment.html>