[Css-csts] Functional Resource Set Names

Tue Nov 5 15:53:35 UTC 2019

Dear Wolfgang,
I can go along with not using just the “TM” qualifier for the Synchronization and Channel Decoding FR Set and FR. However, I find using “Telemetry” instead to be problematic because  (a) it is just the expansion of “TM”, and (b) the point of AOS was that it is more than what is traditionally thought of as “command’ and “telemetry” (also voice, video, video files, etc.). On the other hand, leaving it just unqualified “Frame Synchronization” is perhaps too broad, especially with the possibility of some future use of variable-length USLP on the return link (or the future use of the FR to represent the TC receiving functions onboard a spacecraft). How about “Fixed Length Frame Synchronization and Channel Decoding”? That mirrors the terminology on the sending side. Then it’s applicable to TM, AOS, and FLF USLP frames.

Your subsequent email indicates that you have seen my correction to combine TM and AOS SDLP functionality into common FRs. I confess that I have not confirmed that it will be simple or appropriate to combine AOS and TM Packet Extraction and De-encapsulation, although that is my feeling based on what I know about the two SDLPs. I propose that for now we carry it as a combined FR and schedule it as a “Tier 2” issue due for resolution by, say, the end of February? If it then turns out that it would be inappropriate to combine the two, could we consider putting both FRs in the same FR Set with rules to the effect that it is an exclusive OR situation?

Best regards,
John

From: Wolfgang Hell <wo_._he at t-online.de>
Sent: Tuesday, November 05, 2019 8:43 AM
To: John Pietras <john.pietras at gst.com>
Cc: Holger.Dreihahn at esa.int; harald.ernst at esa.int; Pham, Timothy T (3300) <Timothy.T.Pham at jpl.nasa.gov>
Subject: Re: Functional Resource Set Names

Dear John,,,

I agree with most of the changes that you are suggesting for the Functional Resource Sets. The few concerns I have are the following:

a) TM Synchronization and Channel Decoding: I understand your motivation for not mentioning AOS in the resource set name, but it may be confusing for readers that further down AOS and even USLP frames show up although earlier on it looks like only TM frames are handled. It might therefore be better to use a "neutral" term such a Telemerty (rather than using the TM acronym) or simply talk of "Frame Synchronization".

b) TM Space Link Protocol Reception and  AOS Space Link Protocol Reception: At the Fall Meeting we had agreed that the TM and AOS MC Demultiplexer as well as the TM and AOS VC Demultiplexer should be merged and your latest spreadsheet fr_work_table confirms that decision. Given that I have a problem having separate TM and AOS Space Link Protocol Reception FR Sets. Granted, we have not yet discussed if Packet Extraction & Deencapsulation can be covered by a common TM and AOS type, but regardless we have now the question to which FR Set the TM/AOS MC/VC Demux and Reception FR types belong.

Best regards,

Wolfgang

Am 04.11.2019 um 15:24 schrieb John Pietras:
Dear Wolfgang,
In order to facilitate the future possibility of using some of our current FRs in other node types besides ESLTs (e.g., on space nodes) , we decided to remove the “forward” and “return” prefixes of FR names/classifiers when the sender/receiver nature of the FR could be inferred from other elements of the name – e.g., “Mux” designates the sender side (and thus the forward link from the ESLT’s perspective). However, we did not discuss extending this renaming to the FR Sets that contain those FRs.

Here is my list of proposed modified FR St names. If you agree we can use these in the SANA FRs and the FR Reference Model:

a.       CCSDS 401 Forward Physical Channel Transmission becomes CCSDS 401 Physical Channel Transmission

b.       CCSDS 415 Forward Physical Channel Transmission becomes CCSDS 415 Physical Channel Transmission

c.       CCSDS 401 Return Physical Channel Reception becomes CCSDS 401 Physical Channel Reception

d.       CCSDS 415 Return Physical Channel Reception becomes CCSDS 415 Physical Channel Reception

e.       Forward TC Synchronization and Channel Encoding becomes TC Synchronization and Channel Encoding

f.        Forward Fixed Length Frame (FLF) Synchronization, Channel Encoding, and OID Generation becomes Fixed Length Frame (FLF) Synchronization, Channel Encoding, and OID Generation

g.       Return TM Synchronization and Channel Decoding becomes TM Synchronization and Channel Decoding (Note – although this FR applies to AOS and fixed-length FLF as well, the relevant Blue Book is called “TM …” so that’s the source of the name.)

h.       Forward TC Space Link Protocol Transmission becomes TC Space Link Protocol Transmission

i.         Forward AOS Space Link Protocol Transmission becomes AOS Space Link Protocol Transmission

j.         Forward Variable Length Frame Unified Space Data Link Protocol Transmission becomes Variable Length Frame Unified Space Data Link Protocol Transmission

k.       Forward Fixed Length Frame Unified Space Data Link Protocol Transmission becomes Fixed Length Frame Unified Space Data Link Protocol Transmission

l.         Return TM Space Link Protocol Reception becomes TM Space Link Protocol Reception

m.     Return AOS Space Link Protocol Reception becomes AOS Space Link Protocol Reception

n.       Return Variable Length Frame Unified Space Data Link Protocol Reception becomes Variable Length Frame Unified Space Data Link Protocol Reception

o.       Return Fixed Length Frame Unified Space Data Link Protocol Reception becomes Fixed Length Frame Unified Space Data Link Protocol Reception

The remaining FR Set names do not need to be changed because:

1)      They don’t have “forward” or “return” in them

2)      The “forward” or “return” in their names are from the SLE or CSTS service provider FRs that they contain, or

3)      They are associated with the IOAG Forward File and Return File services (e.g., Forward File Data Delivery Production and Return File Data Delivery Production). However, now that IOAG has subdivided these into CFDP-File services and PACKETS-File services (which may involve different FR types) these FR Sets should be revisited in the future.

Best regards,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20191105/22b38d5d/attachment-0001.html>