[CESG] [EXTERNAL] The history of NASA input for AOS (and USLP) upink in 131.0-B

Fri Feb 21 22:49:10 UTC 2020

Dear Gippo, et al,

Thanks for the history recap for these more recent discussions.  However, I think it is essential to understand the history of the use of AOS and USLP for uplink in the context of CCSDS and IOAG, and not just what has more recently occurred in the context of the delayed 131.0-B updates.  These earlier materials, of course, do not address USLP for uplink or coding, because it did not exist yet.  But these earlier materials do directly address requirements for the use of AOS for uplink, using TM coding, and they date back to at least 2007.

ISS (the single largest international space mission ever flown), notes from John Pietras

The original motivation for the “Enhanced F-CLTU SLE Transfer Service” dates to spring 2007 (or earlier), when the NASA CCSDS contingent (and especially Adrian) wanted to give NASA a robust CCSDS-based solution for transferring R-S-encoded forward-link AOS frames, which was already being used by ISS and was expected to be used by Constellation. ISS had tried to use “regular” F-CLTU, but that approach introduced additional delays (to keep a forward frame buffer full). When we started this work, LDPC had not yet been adopted by CCSDS and (as far as I know) was not being considered for ISS or Constellation. In any case, the original scope was limited to Reed-Solomon and Convolutional coding. I’ve attached a copy of the 26 June 2007 Working Notes from the AOS / F-CLTU Study Team.

Ideally, we would have based our CCSDS solution on what would eventually become the Forward Frame CSTS, but we knew that wouldn’t be available in the desired timeframe (and we were right!). We decided that the most expedient approach would be to extend the existing SLE Forward CLTU service (there was also some idea that NASA HQ might be more amenable to implementing one service that did both AOS and TC vs. F-CLTU and something else. And I believe that this is what SGSS actually decided to do).

By 2009 at the latest, we (NASA) were telling the CSTS WG that NASA wanted to transfer AOS frames over some variant of F-CLTU (October 2009 is the earliest CSTS WG Minutes of Meeting that I can find that mentions this, but I’m pretty sure that we brought it up sooner). WG management took the position that CCSDS would accommodate forward AOS (and any other fixed-length frame protocols) through a new CSTS-based service (which, as previously stated, would be at least several longer than the NASA perceived need date). So NASA sponsored and developed the Orange Book, which for CCSDS is just officially a pathfinding precursor to FF-CSTS but for NASA has become a de-facto standard.

Finally, sometime between 2007 and 2010 LDPC was added to the E-FCLTU specification.
EF-CLTU is an Orange Book, CCSDS 912.11-O-1<https://public.ccsds.org/Pubs/912x11o1.pdf>, published in July 2012.  It specifically identifies the requirement to handle LDPC on the AOS uplink.  See attached page.

IOAG Space Internetworking Strategy Group (SISG) Report, August 2008
This report from the IOAG SISG developed an agreed approach for supporting the development and use of space internetworking, DTN but also IP, in space.  The report included a set of charts with the recommended uses of standards in different deployments, near Earth, Lunar, Mars, etc.  Attached is a page relating to Lunar  environment.  It shows the use of LDPC and BCH over TC and AO links for "Coding DFE" and "Forward Space Link Protocols".  This same report also includes the result of a trade study that you, Wolfgang, and I performed and documented that resulted in the identification of a requirement for what is now referred to as the CSTS Forward Frame service (FF-CSTS).  This was to support AOS over LDPC.  This FF-CSTS service was always intended to be the follow on to the EF-CTLU service, which is why that was left as an Orange Book.

CSS CSTS WG, 2017, notes from Erik Barkley
"the CSS Area first noted the AOS uplink concern at the Spring 2017 meetings, in relation to the FF-CSTS. I sent an email about that earlier this year which is attached for reference."
CSS CSTS WG Executive Summary (from Spring 2017 San Antonio)
Achievements for this meeting cycle:

     *   Forward Frame  CSTS (BB):  Advance white book; secure prototype resources; formalize project   -- on track
     *   …
Problems and Issues:

     *   There are no standards re proper coding/sync/modulation options for forwarding AOS frames for FF-CSTS (scoped for forward service TC and AOS frames); will agencies being use AOS uplink in the future? If so, which agencies and do they commit to interoperable standard?

My conclusion from this is that there were documented mission requirements for AOS over BCH uplink as early as 2007, and for AOS over LDPC as early as 2010.  There are documented IOAG requirements for AOS over LDPC as early as 2008 and they appear in a report that you were one of the contributors to, along with identification of the FF-CSTS service specs that included support for that in a forward service.  You are, and have been, the primary "tender" of the IOAG-CCSDS Product Agreements (ICPA) which should reflect these requirements (https://cwe.ccsds.org/fm/Lists/Projects/IOAG.aspx).

I think it is reasonable to ask why these important mission and IOAG requirements, and the CSS clear identification of the issue, did not immediately result in SLS taking up the issue as a work item sooner?

I will also point out that in Fall 2018 there was not just a "discussion", but a draft set of revisions to 131.0-B was put on the table.  These were almost identical in kind and presentation to those we have recently been discussing in re the DVB spec.  These were rejected and "several lively discussions" ensued, to quote one participant.  But here we are, one and one half years later, and the DVB spec, which is in some ways even more "radical" because it does propose what is in essence "all links, all codes, all directions" has been adopted by the WG and proposed for standardization.  Why was that original submission so controversial and this even more radical one is now acceptable?

Best regards, Peter

From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, February 20, 2020 at 11:58 PM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Cc: "Massimo.Bertinelli at esa.int" <Massimo.Bertinelli at esa.int>, Kenneth Andrews <kenneth.s.andrews at jpl.nasa.gov>
Subject: [EXTERNAL] [CESG] The history of NASA input for AOS (and USLP) upink in 131.0-B

Dear All,
        as it is under discussion in these days, I want to recall everybody the history of NASA input for AOS (and USLP) upink in 131.0-B as based on SLS Reports to CESG and on C&S WG MoMs.

Long time ago at Fall 2017 Meetings [1] it was discovered (thanks to NASA) that the original aim of 131.0-B allowing TM Codes also for uplink was somehow "lost in translation"
It started a long discussion in the C&C with a basic question: As the original TM Coding specs only included Convolutional and RS Codes (with their concatenation) is then reason to open completely the door to any code allowed for uplink?
Different agencies had different points of view in the WG and indeed the discussion was long as painful.

In Spring 2018 there was no input on the matter [2]

In Fall 2018 the matter was discussed again and working group consensus was that modifications including book name changes should be made in parallel to 131.0-B, 131.2-B, and 131.3-B" despite on a very lively discussion with different interpretations [3] and finally <the working group agreed to the text, “Prepare a concept paper to 1) rename, remove link directions and protocols from TM C&S Blue Book, 2) same with SCCC, 3) same with DVB-S2, 4) prepare Profiles Blue Book to enumerate combinations”.>.

In Spring 2019, finally "Consensus on the concept paper was formally recorded with WG resolution to submit it to CMC approval to initiate the work required to implement this update in CCSDS 131.0-B."
Very quickly it was issued a resolution to Start of CWE Project for CCSDS 131.0 “TM Synchronization and Channel Coding” Blue Book Issue 4 [5] and related CWE Project approved [6]. However no NASA input was provided after this approved resolution.

In Fall 2019 there was no NASA input to the WG [7]

Best regards

Gian Paolo

-----------------------------
List of References

[1] C&S MoMs Fall 2017 The Hague, section 2.5 and AI_17_04 (NASA) and eventual SLS Area Report stating for C&S: Agreement to open a new working item (Magenta Book?) to identify which coding options out of CCSDS 131.0-B-3 can be made applicable to uplink AOS
[2]  C&S MoMs Spring 2018 Gaithersburg,  AI_17_04 rescheduled to Fall 2018
[3] C&S MoMs Fall 2018 Berlin, sections 1.8 and 2.1 and AI_17_04 (NASA) Closed; superseded by AI_18_16 and eventual SLS Area Report stating for C&S: Agreed way forward for “AOS Uplink with concepts paper to be submitted soon
[4] C&S MoMs Spring 2019 Berlin, sections 2.4 and AI_18_16 (NASA) still open.
[5] Resolution SLS-R-2019-05-006 dated 9 May 2019.
[6] Poll CMC-P-2019-12-002 closed on 31 Dec. 2019
[7]  C&S MoMs Fall 2019 Darmstadt and  SLS Area Report stating for the related project "No progress in this meeting - Target: Oct 2020"

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or

protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received

this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect

personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20200221/75dbde08/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS 912x11y0 LDPC.pdf
Type: application/pdf
Size: 124622 bytes
Desc: CCSDS 912x11y0 LDPC.pdf
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20200221/75dbde08/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IOAG SISG Report pg 116 Aug 2008.pdf
Type: application/pdf
Size: 441870 bytes
Desc: IOAG SISG Report pg 116 Aug 2008.pdf
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20200221/75dbde08/attachment-0003.pdf>