[Css-csts] Functional Resources and Monitored Parameters

[Wolfgang Hell]

Dear CSTS WG Members,

as a preparation of tomorrow's CSTS telecon, this is to let you know 
where I stand and to identify a number of issues for which we may be 
able to reach an agreement during that telecon.

The work on the Monitored Parameters is for the most part based on
- the related Excel spreadsheet;
- John's Technical Note "Functional Resources for Cross Support Services";
- the list of Managed Parameters identified in the various applicable 
CCSDS Recommendations;
- and for the creation of the XML file the Eclipse based tool developed 
by Holger.

John's Technical Note aims at covering at least those FRs that will be 
needed as to model the production and provision of the services listed 
in the IOAG Service Catalog 1 and the existing SLE service 
specification. I have adopted that set of FRs and have reassigned the 
OIDs (for now) such that now the OIDs are in the same sequence as they 
appear in John's TN. As some initial discussion between John and me has 
shown, chances are that the set of FRs will still change, because due to 
some restrictions of the cardinality of some FR types that John and I 
agreed, it is possible now to merge some FR types. On the other hand, at 
least in one case, introduction of an additional FR type would provide 
for a more consistent monitoring of the forward link multiplexing tree 
structure. Therefore, the present OID assignment may well not yet be the 
final version. Also, right now we have a flat FR structure. It may be 
better to agree on a hierarchical structure along the color coding 
scheme in John's TN. Do you consider the flat OID space good enough?

The work I have done on the forward link FRs reflects the present status 
of the related CCSDS Recommendations and their layering. John pointed 
out that some (not CCSDS approved) implementations allow convolutional 
encoding of the bit stream in a way that is not coupled to the framing 
of the to be encoded data. I'm not sure about the details, but I hear 
rumors that also for the next generation uplink the decoupling of 
synchronization and coding is being discussed. To which extent shall we 
take these considerations into account at this time?

Working on the various FRs I noticed that for whatever reason the set of 
monitored parameters for the forward link is richer than that for the 
return link because quite a number of parameters that reflect the 
configuration rather than any dynamically changing observations have 
been included while that is not or to a far lesser extent the case for 
the return link. A richer set of monitored parameters may be more user 
friendly, but requires more implementation and testing effort. In any 
case, we should apply the same policy to all FRs. That means that we 
either should remove various parameters on the forward side or add 
parameters on the return side. Which way shall we go?

Because of the revised FR types, the specification of the monitored 
parameters has changed quite a bit beyond simply moving an existing 
parameter to a different FR type. As a consequence, a number of the FR 
types are for now specified based solely on my personal judgment. Since 
Holger has created a style sheet, WG members should be in the position 
to review the material that I have generated.

I'm planning to distribute the XML representation of the monitored 
parameters that I managed to create so far this evening. This will be a 
snapshot of work in progress. There are a number of things that are 
still to be done:
- I'm supposed to add the notifications that the existing SLE services 
can issue as events. This is pending.
- The SLE Pink Books will contain more gettable parameters than the 
current Blue Books. These parameters shall be added to the list of 
monitored parameters of the FRs representing these services. I have not 
done that yet.
- For various FR types the XML file contains only the FR type OID but 
not yet any parameter. For those FRs that represent services that are 
not yet specified I plan to leave it that way. However, since it is more 
or less clear what will happen on the service production side, I plan to 
specify the parameters for the production related FRs even if these FR 
types are not needed for those services that are already specified.
- The XML file for now contains an FR type to cover the forward link of 
ranging via a CDMA forward link as per CCSDS 415. If we accept John's 
suggestion (that I fully support) to model a TDRSS kind of forward link 
by means of a dedicated set of FR types, then the FR type as specified 
now for CCSDS 415 needs to be removed.
- John and I agree that we should have some kind of connection-trace 
information which tells which FR instance(s) are supplying input data to 
a given FR instance and which FR instances are consuming which output 
data generated by the given FR instance. The xml file does not yet 
contain suitable monitored parameters.
- John is also proposing to have a monitored parameter which shall 
accommodate descriptive text regarding the role FR instance has in the 
specific configuration. Such descriptive text would be assigned to the 
parameter as part of the overall configuration. Again, the parameter 
required to provide this capability is not yet covered by the XML file.

In addition to the more general considerations listed above I have the 
following questions to John that hopefully we can discuss tomorrow:
- It occurs to me that the naming of the entities in the wide arrows 
showing CFDP related data flow are not consistent (or I'm missing the 
point): The Packet Extraction & De-encapsulation FR type is supposed to 
send CFDP PDUs to 'Forward CFDP'. Shouldn't that read CFDP PDUs to CFDP 
Sending Entity? Likewise the Encap, MAP Pkt Processing & MAP Mux FR as 
well as the TC Encap, VC Pkt Processing & VC Gen FR show CFDP PDUs 
coming from 'Return CFDP'. Shouldn't that read 'from CFDP Receiving Entity'?
- MC-Demux & Reception FR and VC Demux & Reception FR represent 
production activities that are necessary to provide the RCF service. Why 
is the RCF TS Provider supposed to digest all frames rather than taking 
advantage of the demuxing performed by MC-Demux & Reception FR and VC 
Demux & Reception FR? The same question applies to the ROCF TS Provider. 
Since the offline frame buffer contains all frames, also the in case of 
offline delivery mode the MC-Demux & Reception FR and VC Demux & 
Reception FR could do the job. What is the reason for duplicating that 
functionality in the RCF and ROCF TS Provider FRs?
- I understand that the validation of radiometric products made 
available via offline delivery is not shown in the FR type figures. But 
why is the correlator that consumes the DDOR raw data from two locations 
and calculates the associated TDM formatted product not shown either? 
How shall the production and delivery of that product be modeled?

Talk to you tomorrow.

Best regards,
Wolfgang