[CESG] RE: Follow up re CMC-A-2015-05-04

[Barkley, Erik J (3970)]

Nestor,

I had a chat with Wallace today, and my understanding is that the action item, although somewhat awkwardly phrased, is really the CMC just asking to limit the scope of forward and return file to be simply an injection into and extraction from CFDP.  This was already understood to be one of the use cases so that is okay.  I’m also okay considering a smaller scoped activity as that will, of course, mean less resource commitment, less to develop and potentially prototype (it seems like something like this would probably need to be prototyped – but that is not really for discussion here).

Do you agree with this?  If so, I think we can close the action as agreeing to limit the scope to interfacing with CFDP.

Best regards,

-Erik

From: Barkley, Erik J (3970)
Sent: Tuesday, June 02, 2015 3:47 PM
To: Nestor.Peccia at esa.int; Tai, Wallace S
Cc: Margherita.di.Giulio at esa.int; CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org) (cesg at mailman.ccsds.org)
Subject: Follow up re CMC-A-2015-05-04

Nestor, Wallace,

For your convenience here is what the action states:

CMC-A-2015-05-04

The Cross Support Services Area was requested to consider using Terrestrial Generic File Transfer Service along with the CFDP File Structure to replace the following two standards: CSTS Forward File Service (CFFS) and CSTS Return File Service (CRFS).
Action: Cross Support Services Area
Due Date: 30 June 2015
Status: Open



Summary response:
I do not understand what is being asked to be considered here.   I believe the CSS Area is properly investigating the use cases indicated by the IOAG service catalog definition.

More detailed discussion follows.   Your inputs on helping to clarify what this action is asking for will be appreciated.

Best regards,

-Erik

---More detailed discussion for forward side---

For reference, here is what the IOAG service catalog, June 2013 version, has to say about forward file service.  I have added some comments in red.

FORWARD FILE SERVICE TYPE
This Service enables a mission to send the contents of a file to a spacecraft by allowing a Control
Center to provide a Ground Tracking Asset with files for uplink. [NOTE: this states the contents of the file to be sent to the mission spacecraft, not the file; what is being provided from the mission to the control center is the file]

Within Catalog #1, usage of this service is limited to a spacecraft directly reachable from a Ground Tracking Asset (i.e. single hop
space link) as per Figure 2-1. It relies on the same Space Link Interface Standards applicable to
“Forward CLTU Service” (see 4.1.1) and/or “Forward Synchronous Encoded Frame Service” (see
4.1.3) plus the following Space Link Interface Standards and Ground Link Interface Standards.
• Space Packet Protocol [SPP]
• Encapsulation Service [ENC]
• CCSDS File Delivery Protocol [CFDP]
• CSTS Forward File Service [CFFS] over
• CSTS Transfer File Service [CFXS]
• TM Synchronization and Channel Coding [TM-S&C]
• AOS Space Data Link Protocol [AOS]
Remark - The two CSTS File Services listed above are “to be written”. It is assumed that a generic
transfer file service allowing to transfer files between two units, i.e. [CFXS], will be available and
- on top of this generic service – more “specialized” file services will allow requesting the
dedicated processing for the file being transferred. Therefore, it is expected that the CSTS Forward
File Service will allow the Control Center to inform whether the file contains

·         a collection of Space Packets, or

·         a collection of Encapsulation Packets, or

·         a file to be processed into CFDP PDUS to be embedded either in Space Packets or
Encapsulation Packets.
Additionally the CSTS Forward File Service will allow the Control Center to state how the
Space/Encapsulation Packets shall be forwarded to the spacecraft either within TC Frames or AOS
Frames.

These statements:

“…Therefore, it is expected that the CSTS Forward
File Service will allow the Control Center to inform whether the file contains

·         a collection of Space Packets, or

·         a collection of Encapsulation Packets, or

·         a file to be processed into CFDP PDUS to be embedded either in Space Packets or
Encapsulation Packets.
Additionally the CSTS Forward File Service will allow the Control Center to state how the
Space/Encapsulation Packets shall be forwarded to the spacecraft either within TC Frames or AOS
Frames.”

Strongly suggest to me that we are to consider that the file coming from the mission to the ground station control center may contain various space link artifacts,  in a file, and that the file is to either be unpacked and properly placed on the spacelink or to be an injected into CFDP instance that is terminated at the ground station (and subsequently uplinked as CFDP).  Based on that I believe the CSS area is properly investigating the set of use cases for a potential forward file service.  Its unclear to me how considering CFDP file structure to eliminate the forward services envisioned (as I understand it) in the IOAG catalog really does anything to eliminate the use cases identified here.


---More detailed discussion for return side---

From June 2013 IOAG Svc Cat 1:

RETURN FILE SERVICE TYPE
This Service enables a mission to send the contents of a file to a Control Center by allowing a
Ground Tracking Asset to provide a Control Center with files received from a spacecraft. [Note that this is again is the contents of a file (not a file) on the spacelink, with the file itself being on the ground; in this case just running in the opposite direction as forward side]  Within
Catalog #1, usage of this service is limited to a spacecraft directly reachable from a Ground
Tracking Asset (i.e. single hop space link) as per Figure 2-1. It relies on the same Space Link
Interface Standards applicable to “Return Channel Frames Service” (See 4.2.2) plus the following
Space Link Interface Standards and Ground Link Interface Standards.
• Space Packet Protocol [SPP]
• Encapsulation Service [ENC]
• CCSDS File Delivery Protocol [CFDP]
• CSTS Return File Service [CRFS] over
• CSTS Transfer File Service [CFXS]
Remark - The two CSTS File Services listed above are “to be written”. It is assumed that a generic
transfer file service allowing to transfer files between two units, i.e. [CFXS], will be available and
- on top of this generic service – more “specialized” file services will allow requesting the
dedicated processing for the file being transferred. Therefore, it is expected that the CSTS Return
File Service will allow the Ground Tracking Asset to inform the Control Center whether the file
contains

·         a collection of Space Packets, or

·         a collection of Encapsulation Packets, or

·         a file reconstructed from CFDP PDUS that were embedded either in Space Packets or
Encapsulation Packets. 8
Additionally the CSTS Return File Service will allow the Ground Tracking Asset to report whether
the Space/Encapsulation Packets were transmitted from the spacecraft either within TM Frames or
AOS Frames.9


This seems very much to me to be the mirror image of the forward side; in this case, spacelink artifacts are being  gathered up for delivery as a file or being gathered up for what can be inferred as ground domain CFDP only.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150606/5272e5fa/attachment.html>