[Css-csts] Functional Resource Set Names - correction

[John Pietras]

Dear Wolfgang,
I forgot that we had agreed to let AOS and TM have a shared FR Set for reception. Likewise, we will have a single FR Set for USLP reception that covers both FLF and VLF. So in the list below replace items (l) through (o) with the following:

l.        Return TM Space Link Protocol Reception and Return TM Space Link Protocol Reception combine to become TM/AOS Space Link Protocol Reception
m.     Return Variable Length Frame Unified Space Data Link Protocol Reception and Return Fixed Length Frame Unified Space Data Link Protocol Reception combine to become Unified Space Data Link Protocol Reception

Best regards,
John

From: John Pietras
Sent: Monday, November 04, 2019 9:24 AM
To: Wolfgang Hell <wo_._he at t-online.de>
Cc: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>
Subject: Functional Resource Set Names

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/20191104/ad006ad1/attachment.html>