[Sls-rfm] Notes from today's SEA SAWG Coordination meeting on the SCCS-ARD document updates
Jon Hamkins
Jon.Hamkins at jpl.caltech.edu
Thu Jul 8 00:23:24 UTC 2021
Enrico, Andrea,
In response to your request to provide suggestions and copy the mailing
list about the Space Communication Cross Support Architecture
Requirements Document, below I provide the feedback I gave to Peter
Shames immediately after the June 23 meeting on this topic. Attached for
convenience are the slides being commented upon.
***
Clearly a lot of effort has gone into this. At some point I would like
to go over the Section 6 tables and things in more detail, and it may be
some time before I will be able to do so. But before things get too far
down the track, I wanted to write to you now regarding the treatment of
VCM. This is meant in the spirit of constructive criticism and leading
to a better result for the SCCS-ARD. Here are some detailed thoughts.
I confess that I don't see a convincing case for including substantial
VCM material in the SCCS-ARD. Unless a good case can be made for why we
need it, I suggest that we plan to leave it out, except for describing
the interface to the physical layer, which is where the jig-saw pieces
meet and description actually is missing from the Blue Books. I think
there are some good reasons why VCM in SCCS-ARD is not needed:
* The current SCCS-ARD, published in 2015, does not describe or refer
to "VCM" anywhere, even though two VCM-related Blue Books were years
old by that point. I have not heard anyone complain that more VCM
description was needed than what was in the Blue Books in order to
understand how things fit together.
* Since then, we have published a VCM Blue Book that describes the
unified protocol, with the differences between the two Blue Books
described as Type 1 and 2 variants. I believe the original two
books, together with the 431 book, make all of the necessary
normative statements needed about how VCM works.
* The purpose of the SCCS-ARD is to describe how the CCSDS standards
fit together. That is already what 431 does, when it comes to VCM.
In fact, we had envisioned the 431 book as a Magenta book,
explaining how the common VCM protocol described in the SCCC and
DVB-S2 standard could be used in conjunction with the TM codes.
* There is no inter-operation between SCCC and DVB-S2, making a
diagram showing the details of them together on one page unnecessary
in the SCCS-ARD.
* There is less need to describe VCM than other standards in the
SCCS-ARD, because there are fewer jig-saw puzzle pieces to stitch
together. The SCCC and DVB-S2 books are silos that are
self-contained with multiple layers included.
I also have comments about the slides themselves.
* "CCSDS has 3 VCM standards" is poorly worded.
o We've always referred to SCCC and DVB-S2 as coding standards,
together with some textbook modulations. And yes, a VCM
protocol. But I wouldn't call them "VCM standards." The VCM was
an ancillary, feather-in-the-cap feature of these new coding
standards. All of the debate about these standards was about the
complexity, performance, maturity, etc. of the codes.
o In fact, the VCM protocol in the SCCC and DVB-S2 books is nearly
identical, with the same header in the same place and of the
same length using the same coding protection and same pi/2
modulation. Also, the same architecture is used for pilot
symbols, for shaping, and near-identical modulation options. The
431 VCM book allows use of the same VCM protocol with the TM
codes. With one VCM protocol used with many codes, I think it is
a misleading to call that "3 VCM standards."
* I think the VCM figure makes things more complicated and harder to
understand than they actually are.
o My main issue is that the figure fails to highlight that CCSDS
has a unified VCM protocol which can be used in conjunction with
the three coding options SCCC, DVB-S2, and TM turbo/LDPC. The
figure makes it seem that everything about the signal flow is
different at every step in the three books.
o A second main issue is that for a diagram purportedly about VCM,
there is little about how the VCM modes are signaled in the
header. Frame Descriptor and Physical Layer Signaling aren't
even mentioned, and those are the crux of the VCM architecture.
o The term "VCM suite" is introduced. This is a new term with no
value or tie back to the Blue Books. It may mislead the reader
into thinking there are fundamentally different VCM protocols,
which I think is the opposite of what this figure should be doing.
o The "CCSDS VCM Protocol" is shown as a block in the middle, when
in reality as described in 431 it encompasses both the SCCC and
DVB-S2 protocols.
o It is unclear from this diagram that SCCC codes use Type 1 VCM
and DVB-S2 use Type 2 VCM
o The things that are common -- functions like slicing, ASM,
modulation, pilot -- are drawn multiple times, giving the
impression that they are different.
o The slicer for DVB is shown within the ETSI standard, when it is
really part of the CCSDS standard (131.3).
o The boxes labeled "variable coding and modulation" contain no
coding and no modulation. I think you mean VCM control.
o No VCM control is shown for the TM codes.
o No VCM control is shown for the pilots.
o No VCM control is shown for the slicer.
o Arrows showing direction of flow are missing throughout.
o The circle-plus notation in the figure is confusing. In other
CCSDS standards, that notation means XOR, which is not what is
going on here.
* Regarding the all stacks diagram on p. 24
o One area I think the SCCS-ARD could help with is making explicit
that SCCC, DVB-S2, and TM coding books interface to the RFM 401
book. P. 24 does a reasonable job of this, showing the RFM below
the SCCC and DVB-S2 codes and it should be backed up with words.
o Again, p. 24 has a box called "VCM suite," and all of SCCC and
DVB-S2 and 431 are hidden inside that box, which doesn't make
sense. They are each their own blue book.
o Please be aware that reasonable people see different boundaries
for the physical layer. The SCCC and DVB-S2 books define the
modulations, and the RFM book /also /defines the modulations.
Whether you choose to believe modulation is in the physical
layer or the coding sublayer is a matter of taste. In the
optical standards, for example, the physical layer is limited to
physical quantities (frequencies, polarization, linewidth,
etc.), and modulation is considered to be in the coding
sublayer. That is because the modulation is part of the code.
But the way p. 24 is drawn implies an inconsistent
interpretation what layer modulation is in. You can't fix that,
as the blue books have this inconsistency.
----Jon
*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*JPL* | jpl.nasa.gov
On 6/24/2021 2:05 AM, Enrico.Vassallo at esa.int wrote:
> Dear All,
>
> please find the above mentioned attached presentation and some notes.
>
> Feel free to ask any questions you may have or provide suggestions
> directly to Peter while copying the whole RFM WG mailing list.
>
> Enjoy the reading,
>
> Enrico
> ----- Forwarded by Enrico Vassallo/esoc/ESA on 24/06/21 11:03 -----
>
> From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
> To: "CCSDS Engineering Steering Group - CESG Exec"
> <cesg at mailman.ccsds.org>, "Enrico.Vassallo at esa.int"
> <Enrico.Vassallo at esa.int>, "D'Amore Giuseppe"
> <giuseppe.damore at asi.it>, "Gilles Moury" <Gilles.Moury at cnes.fr>,
> "Colin Haddow" <Colin.Haddow at esa.int>, "Andrea.Modenini at esa.int"
> <Andrea.Modenini at esa.int>, "Lee, Dennis K (US 332G)"
> <dennis.k.lee at jpl.nasa.gov>, "Ignacio.Aguilar.Sanchez at esa.int"
> <Ignacio.Aguilar.Sanchez at esa.int>, "EXTERNAL-Pietras, John V (US
> 332C-Affiliate)" <john.pietras at gst.com>, "Andrews, Kenneth S (US
> 332B)" <kenneth.s.andrews at jpl.nasa.gov>, "Barkley, Erik J (US 3970)"
> <erik.j.barkley at jpl.nasa.gov>, "Hamkins, Jon (US 3300)"
> <jon.hamkins at jpl.nasa.gov>, "Pham, Timothy T (US 3300)"
> <timothy.t.pham at jpl.nasa.gov>, "Bernie Edwards"
> <bernard.l.edwards at nasa.gov>, "Volk, Christopher P (US 335D)"
> <christopher.p.volk at jpl.nasa.gov>, "Ramon Krosley"
> <r.krosley at andropogon.org>, "Kazz, Greg J (US 312B)"
> <greg.j.kazz at jpl.nasa.gov>, "Ricard.Abello at esa.int"
> <Ricard.Abello at esa.int>, "Javier.DeVicente at esa.int"
> <Javier.DeVicente at esa.int>, "Howie Weiss" <Howard.Weiss at parsons.com>,
> "Keith Scott" <kscott at mitre.org>, "Mario.Merri at esa.int"
> <Mario.Merri at esa.int>, "he xiongwen" <hexw501 at hotmail.com>,
> "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, "Lotten
> Bergstroem (external)" <Lotten.Bergstroem at esa.int>, "Wilmot, Jonathan
> J. (GSFC-5800)" <jonathan.j.wilmot at nasa.gov>, "Klaus-Juergen Schulz"
> <Klaus-Juergen.Schulz at esa.int>, "Enrico.Vassallo at esa.int"
> <Enrico.Vassallo at esa.int>
> Date: 24/06/21 00:53
> Subject: Notes from today's SEA SAWG Coordination meeting on the
> SCCS-ARD document updates
> ------------------------------------------------------------------------
>
>
> Dear SLS, CSS, SIS, SEA, and SOIS colleagues,
>
> We just held a meeting to review the proposed set of changes that the
> SEA Systems Architecture WG (SAWG) is working on to revise the Space
> Communication Cross Support Architecture Requirements Document (CCSDS
> SCCS-ARD, 901.1-M-1). That document presently describes how more than
> fifty-seven (57) normative CCSDS standards may be fitted together,
> like some giant jig-saw puzzle, to mee the needs of users who design
> and build flight and ground communications assets. In the time since
> that standard was published a number of these normative standards have
> been updated, some with new features, and a significant number of new
> standards have been published, especially in SLS and CSS, but also in
> SEA itself.
>
> We reviewed the major issues we identified with the current document
> structure that requires changes to the chapters for clarity of
> presentation. We also reviewed some of the complexities introduced by
> new standards, such as USLP, optical comm, VCM, and newer security
> features that are driving a change in approach. And we discussed
> adding all of the new standards that have been introduced since this
> document was published.
>
> We are attaching the presentation where we discussed these issues and
> how we plan to address them. This is an unusual request for a WG,
> which typically do this sort of work behind closed doors, but since
> this document cross cuts all of your WGs we thought it useful and, we
> hope, valuable to you. Since we have focused on ABA deployments the
> only Area that is not directly affected yet is SIS. SOIS, and others,
> also raised some issues having to do with relay architectures,
> off-Earth instances of what are essentially treated as Earth-bound
> ESLT services in the ABA context. Most of this will be addressed in
> the “ABCBA” and Solar System Internet (SSI) configurations that are
> in the next batch of updates.
>
> I am attaching the presentation here. Please review it in the context
> of the current CCSDS 901.1-M-1 document, which these changes will
> update. In particular, for SSI and relay sorts of configurations, the
> SSI sub-sections, even as they are now, should provide the necessary
> framework of functions, deployments, and examples to cover these
> future concerns.
>
> What follows is my scribbled notes from the WebEx. If there are any
> issues please provide corrections so that we have a “complete enough”
> of minutes with which to make progress in resolving issues.
>
> Last comments: This is a complicated set of topics, with some
> distinct, if not clearly articulated, sets of relationships. In this
> document we wish to make these as clear as we can. In some cases we
> have identified open issues that we, the CCSDS members, really ought
> to address. And in some cases we have new people, in new leadership
> positions, who will need help to understand the complexities and to
> help lead us to satisfactory, consensus-based, outcomes. My personal
> request is that we try and work together, for the greater good, to
> develop and document outcomes that work for all of us and our user base.
>
> Thanks, Peter
>
> *Brief Meeting Notes – 23 June 2021*
>
> Attendees: Shames, Krosley, De Cola, Pham, Vassallo, Sanchez-Aguillar,
> de Vicente, Hamkins, Volk, Haddow, Calzolari, Edwards, Kazz, Barkley,
> Wilmot, Schulz, Modenini (_please update if I left anyone off this list_)
>
> Discussion notes: relative to pages in the attached presentation
>
> Pgs 5-6, Andrews: What is the relationship of this CCSDS 901.1-M-1
> SCCS-ARD doc to the existing SLS Overview of Space Communication
> Protocols (OSCP), CCSDS 130.0-G-3? Do we need both?
>
> Answer: The OSCP is a useful doc, and it covers the SLS (and some
> SIS) protocol stack, but the OSCP is not an architecture document and
> it does not address CSS at all, nor really much about SIS. It may
> be a useful companion to the the SCCS-ARD, but it is much more
> limited in coverage of topics and only addresses a limited set the
> protocol stack and deployment issues. It is up to SLS to determine
> whether they wish to retain this document.
>
> Pg 6, Calzolari: Raised the issue of the “Forward / Return File
> service, that it is a low IOAG priority (stated as “minus infinity”),
> and that agencies are doing as they wish to implement some sort of
> “split mode” CFDP file delivery agent.
>
> Answer: Agreed that this is a low priority for CCSDS, and that it may
> be better for CCSDS to reject it, but that is not the role of this WG,
> we just make note of such problems. Agreed that Agencies are free to
> implement “split mode CFDP” in any way they deem suitable, but that
> this is not a standard approach nor is it likely to be cross-supported.
>
> Pgs 8-9: The group agreed that the use of the proposed revisions to
> Sec 4, and the new tables in Sec 6, made a lot of sense and were much
> clearer than the alternative.
>
> Pg 11, Schulz: There was a later question as to whether this document
> is just listing possible options or making concrete recommendations
> about selections of future standards that are preferred.
>
> Answer: The inclusion of “R<n>” markings in various tables are, in
> fact, intended to draw attention to the CCSDS Recommended paths
> forward. We can, and should, revisit this as a group and provide such
> guidance wherever we can. One stated example is recommending use of
> USLP for high rate, bi-directional, mission comms, such as for human
> rated missions, along with FF-CSTS.
>
> Pg 12, Pham: The question was raised about inclusion of the EF-CLTU
> Orange Book in this document, particularly in Sec 4 Services, because
> it is of interest to the ISS and Artemis missions. This also came up
> again in the context of Table 6-8, pg 17.
>
> Answer: There is agreement that we do need to address the use of this
> Experimental, Orange Book, spec for these important missions, but also
> agreement that we should not warp the already complicated structure
> of this document to meet the needs of these slow moving missions that
> are retaining these older protocols. The recommendation is to put a
> new Note (N4) in table 6-8 (see pg 17) to the effect that while AOS
> forward links are recommended to be supported by FF-CSTS, that they
> may be supported, in CLTU form, using F-CLTU or the obsolescent
> EF-CLTU. A similar note may be useful in Sec 4.
>
> Pgs 12-20, Andrews: Ken raised a question about the meaning of the
> column headings in the tables on pgs 12-20. In many cases the column
> headers are observed to be the same as the protocol names on the rows.
> What are these really intended to represent? Barkley wanted to make
> sure that “Interface Binding Signature” is clearly defined in the
> document.
>
> Answer: The column headers are really intended to name the
> Service/Function that is being provided. The rows are intended to map
> out the stack of protocols that support that service interface, which
> is, in effect, the interface binding signature for the service.
> Recommendation is to reword the column headers to reflect their role
> as Service / Function (e.g “Deliver tracking data” instead of TD-CSTS)
> and the row entries as the protocols that form the “stack”.
>
> Pg 14, Haddow/Barkley: The question of just what was meant by “Raw
> Radiometric” data, or, for that matter, “Validated Radiometric” data
> was raised. This is in the context of using TGFT [64] and XFDU as the
> transport method and data format.
>
> Answer: Agreed that the XFDU format, required content description,
> must be provided in order for the use of TGFT to make sense. Agreed
> that this is an issue that the MOIMS Nav WG is in the best position to
> address.
>
> Typo? There was also a question about the “N” in the Raw Radiometric
> column of this table instead of an “M”?
>
> Pg 14, de Vicente/Volk: The question of just how the D-DOR WG
> currently returns their voluminous file data, using the RDEF [38]
> formatted files was raised.
>
> Answer: The response shown, using SFTP, was stated to be accurate. We
> need a reference for this.
>
> Pg 15, Haddow/Barkley: Why is HTTP over TLS [55] the protocol shown to
> carry SM “information entities”?
>
> Answer: This is intended to be future looking, and SM transport
> protocol is likely to be HTTP/REST therefore it is safe (enough) to
> use it in this table as a [Future] protocol. Agreed.
>
> Pg 17, Sanchez-Aguilar, Pham, Schulz, and others: This table generated
> a lot of discussion. We traced AOS and TC, in particular, down
> through the stacks and into the notes. There was agreement that this
> was a pretty good way to describe all of the complexities inherent in
> what has, in fact, been standardized. There was also a strong desire
> to understand just what we were trying to describe and to review these
> tables in detail.
>
> Issues:
>
> 1. How does the TC path work?
>
> 2. How does the AOS path work?
>
> 3. How do the USLP (fixed and variable) path(s) work?
>
> 4. Why does F-CLTU for TC S&CC reference C2 which is only about
> optical comm?
>
> 5. Can we put a note, N4, into the cell for AOS forward and F-CLTU
> indicating that both F-CLTU, and EF-CLTU, can be used, with some local
> wrangling, to support synchronous AOS forward links, but that FF-CSTS
> is recommended?
>
> 6. Just how much of what is in this table should be shown as
> “Recommended” as opposed to just “Optional”
>
> Answer: Table still needs work and probably a new N4 note, at a minimum.
>
> Request: That this group undertake a careful review to make sure that
> these tables make sense and that they are accurate.
>
> Pg 17, Sanchez-Aguilar, Wilmot: How does this table address TC
> commands sent from a relay, or a relay S/C running DTN to a leaf node
> over a local / proximate protocol such as WiFi?
>
> Answer: All of these sorts of ABCBA and SSI deployment questions will
> be addressed in the SSI sub-sections of the document which will be
> worked in the next round of edits. The SSI sections in the current
> edition should be reviewed with an eye toward whether this already
> provides a viable framework for such discussions. It defines a pretty
> broad variety of node types and possible / example configurations.
>
> Pg 18, Schulz: What is the role of this document? Is it to provide
> recommendations or just documentation?
>
> Answer: There is the intent to provide recommendations of best options
> where we can reach consensus on what those might be. See discussion
> on pg 11. We will provide the current */draft/* document, and the
> “R<n>” parts to anyone who requests it.
>
> Pg 21-24, Barkley: Is any simplification of the whole complex set of
> three almost identical VCM protocols going to be possible? It seems
> that Agency interests drove us to this awkward and complicated situation.
>
> Answer: While the SEA SAWG would also like to get this situation fixed
> we are in the same situation as we stated in Pg 6 (and 29-30) in
> regard Fwd/Ret CFDP. It is up to the CCSDS Areas and WG to fix this
> stuff up. The best we can do is to point out that there are issues
> and to attempt to describe them as clearly as possible. We would like
> to encourage that this be done, the current situation is awkward, at best.
>
> 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).
>
> _______________________________________________
> SLS-RFM mailing list
> SLS-RFM at mailman.ccsds.org
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm__;!!PvBDto6Hs4WbVuu7!drNJuVdVuDeS8T4RT9_swProBOul7HtBi6LFjDkS-whoICkr160iOWcJNKgrhzlrAq7EnLrh$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20210707/8dcb9959/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCCS-ARD_5yr_refresh-210623.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1426404 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20210707/8dcb9959/attachment-0001.pptx>
More information about the SLS-RFM
mailing list