[Sls-rfm] [SLS-CC] Fw: WebEx meeting invitation: SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
Jon Hamkins
Jon.Hamkins at jpl.nasa.gov
Mon Nov 15 07:05:12 UTC 2021
Thank you for the invitation to review the SCCS-ARD. I regret that I
will not be able to discuss the SCCS-ARD in person on 23 Nov. I will be
on vacation that week. I give my comments here, with the hope that this
is enough in advance of the meeting for each of the individual comments
to be read and discussed at the meeting.
My primary comment is that updating the SCCS-ARD is clearly a large
undertaking, and I would like to congratulate John Pietras and Peter
Shames for on the production of a quality document. It is difficult to
absorb such a large swath of CCSDS standards and integrate them into a
helpful summary of the interfaces as this SCCS-ARD does.
My other comments primarily relate to the new VCM content. There are six
main comments, with more detailed description, recommendation, and
justification for each. These comments are written based on the latest
SCCS-ARD, but I also repeat portions of my June-23 comments if they were
not yet addressed. I believe the SCCS-ARD will be much improved if we
adopt these recommendations.
* The phrase "VCM suite"
o Description: This phrase is introduced in this SCCS-ARD. It
occurs in Table 6-1, and throughout Section 6.1.2, Table 6-8,
Table 6-12.
o Recommendation: Remove this phrase in all places and replace
with "the VCM protocol."
o Justification
+ CCSDS does not have a "VCM suite" and I think it is a
mistake to invent this new concept here, especially since it
would risk confusing the reader into thinking that there is
more than one VCM protocol.
+ 131.2 and 131.3 are not members of a supposed "VCM suite."
They are not even the same kind of thing that 431.1 is.
431.1 is a protocol book, while 131.2 and 131.3 describes
codes, modulation, and VCM.
+ One VCM protocol. As we worked out in the C&S and RFM WGs at
the time we negotiated the VCM protocol blue book
(431.1-B-1), there is one VCM protocol that can be used with
multiple sets of codes and modulations described in other
blue books. There are some variations and options in this
protocol, but it is fundamentally one protocol that operates
in the same way, namely, with a header signaled with
pi/2-BPSK and protected with a specific RM code, followed by
code symbols using a higher order modulation. This is why
the VCM blue book has the title "Variable Coded Modulation
Protocol" with no plural word or "suite."
+ In other words, the protocol is singular. What is plural is
the set of VCM tables that can be used in conjunction with
the protocol. Incidentally, in other areas CCSDS doesn't
refer to a "code suite," or a "ranging suite" or a
"frequencies suite" where there are clearly multiple options.
* Table 6-1 organization.
o Description: Table 6-1 lists three references for the VCM
"Suite": 131.2, 131.3, and 431.1.
o Recommendation: put 131.2, 131.3, and 431.1 each on their own
row of the table, using their Blue Book name, like the other
rows of the table do.
o Justification
+ Books that are the same type of thing are treated
differently in the table.
# As we know, there are 4 CCSDS coding standards that
ingest TM/AOS/USLP frames (what we might previously call
space-to-ground links): 131.0 (turbo/LDPC), 131.2
(SCCC), 131.3 (DVB-S2 LDPC), and 142.1 (SCPPM). These
references should appear together in Table 6-1 in the
same way, not with 131.0 in its own row and 131.2 and
131.3 relegated to a secondary category within "VCM
suite." The SCCS-ARD should be about interfaces (in this
case, ingestion of TM, AOS, or USLP Transfer Frames).
Treating them differently in the table doesn't make sense.
# In particular, Table 6-1 as written calls out 142.1 and
131.0 as "coding" books and 131.2 and 131.3 as members
of a supposed "VCM suite." But 131.2 and 131.3 are
primarily about the codes they define -- the SCCC codes
and DVB-S2 LDPC codes. When C&S negotiated their
acceptance, the discussion was primarily about the
coding performance, complexity, maturity, etc., and not
their associated VCM approaches (which are nearly
identical).
+ Books that are different are treated as though they are the
same in the table
# 131.2, 131.3, and 431.1 cannot be listed as though they
are the same type of thing
# 431.1 is fundamentally different in structure from 131.2
and 131.3. 431.1 is the unifying description of the
(one) CCSDS VCM protocol, and refers back to 131.2 and
131.3 in describing the differences of the two minor
variations (types). Whereas 131.2 and 131.3 describe
codes and modulations.
+ This would be consistent with the rest of the table.
* Table 6-1 "space-to-ground links".
o Description: The table has a left-column heading labeled
"Space-to-Ground Links."
o Recommendation:
+ Remove or reword "Space-to-Ground Links"
o Justification:
+ This may be outdated terminology, given our renewed interest
in allowing a variety of link directions for the standards.
+ Or, if we are keeping the concept of direction, why is the
TC coding book listed in this category? Also, why is there
no corresponding "Ground-to-Space Links" category?
* Figure 6-1
o Description: Figure 6-1 shows boxes for TM sync and channel
coding, VCM suite, and RF and modulation, with some lines
between some of them.
o Recommendation: Revise the figure to include an "SCCC coding"
box, a "DVB-S2 LDPC coding" (or similar) box, and redraw the VCM
box to encompass those boxes as well as the "TM sync and channel
coding" and "RF and Modulation" boxes. Also, update the lines to
make clear which frame types may enter each of the boxes on the
coding sublayer.
o Justification: As drawn, this figure is not clear and bordering
on inaccurate.
+ There is a box labeled VCM suite, presumably meant to
include 131.2, 131.3, and 431.1 in this box. If so, then why
is TM Sync And Channel Coding outside of this box? Why is RF
and Modulation outside of this box? Those are specified as
part of 431.1.
+ It does not make sense for turbo/LDPC codes to get their own
box in this figure, but not SCCC and DVB-S2 codes. These
make the same type of specification at the same layer. Where
SCCS-ARD can be of service is in explaining where the
interfaces are the same in the various books.
+ VCM is a standard about both coding and modulation and so
should be drawn to encompass the coding and modulation
functions.
* Section 6.1.2.2.1
o Description. This section:
+ States that the VCM suite is not a single protocol but
rather three separate protocols, then says they are "very
similar," and finally then says they are all subsumed into
one, using the phrase "the VCM protocol."
+ Refers to 131.2 and 131.3 as "VCM standards"
+ Says that 431.1 subsumes the functionality of 131.2 and 131.3
o Recommendation: Rewrite the paragraph from scratch to include
these features
+ Refer to 131.0, 131.2, and 131.3 on equal footing as
standards for turbo/LDPC, SCCC, and DVB-S2 LDPC codes, and a
variety of modulations.
+ Refer to 431.1 ("the VCM protocol") as allowing the codes
specified in these three standards to be used with a common
protocol with two variations called Type 1 and Type 2; and
that the VCM protocol is easily updated to accommodate other
codes and/or modulations with the additional of new VCM tables.
o Justification:
+ As written, the paragraph is self-contradictory. The
protocol cannot simultaneously be three separate things, two
very similar things, and all subsumed into one thing.
+ The simplicity of the concept of unifying VCM into a common
protocol that can be used with SCCC, DVB-S2 and turbo/LDPC
codes is missing from this paragraph.
+ Saying 431.1 "subsumes" 131.2 and 131.3 makes it seem like
131.2 and 131.3 are not needed. They are needed, because
they are what specifies the codes and modulations. 431.1
/refers/ to 131.2 and 131.3.
* Figure 6-2
o Description. The figure purports to show component standards of
"the VCM suite."
o Recommendation:
+ Remove this figure from the SCCS-ARD.
o Justification. This figure is unnecessary, redundant,
artificially complex, misleading, and incomplete.
+ Unnecessary
# There is no "VCM suite."
# The purpose of the SCCS-ARD is to explain how things fit
together. But this figure purportedly shows three
standards -- 131.2, 431.1, and 131.3 -- /that do not
interact with each other/ (there are no lines between
the three main boxes)/. /This makes it unnecessary for
the SCCS-ARD to address.
+ Redundant, artificially complex
# No information would be lost if the 131.2 and 131.3
columns were deleted in their entirety. All of the SCCC
encoding is shown within the middle (431) box, for
example. This duplication is confusing and artificially
adds complexity where there is none.
# The things that are common -- functions like slicing,
ASM, modulation, pilot -- are drawn multiple times,
giving the impression that they are different.
# There is so much stuff on this figure that it has been
shrunk so that the font is 6 pts. This is not legible
without zooming.
+ Misleading
# The duplication mentioned above may confuse a reader
into believing that there is more than one VCM protocol
that applies to SCCC codes (similarly, for DVB-S2
codes). This is the opposite of what this figure should
be doing.
# The slicer for DVB is shown within the ETSI standard,
when it is really part of the CCSDS standard (131.3).
# The boxes labeled "variable coding and modulation"
contain no coding and no modulation. I think you mean
VCM control.
# 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.
+ Incomplete
# Few of the salient features of the VCM protocol are
actually present in the figure. The VCM header is
transmitted with pi/2-BPSK modulation, for example. The
pilots are optional. The header has two parts, a sync
marker and a signaling structure (PLS or frame
descriptor). The frame descriptor is protected with a
(32,6) code. All of that is missing.
# The input to the "VCM suite" is not labeled. The
interfaces are the most important part of showing how
things fit together.
# The output of the "VCM suite" is not labeled. Again,
that should be the important part.
# No VCM control is shown as an input to the TM codes.
# No VCM control is shown for the pilots.
# No VCM control is shown for the slicer.
# Arrows showing direction of flow are missing throughout.
----Jon
*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*O* 818-354-4764 | *M* 626-658-6220
*JPL* | jpl.nasa.gov
On 11/10/2021 11:58 PM, Andrea.Modenini at esa.int wrote:
> FYI
>
> *ESA - European Space Agency*
> *Ph.D. Andrea Modenini**
> TT&C Communications Systems Engineer***
> TT&C and PDT Systems & Techniques Section (TEC-EST)
> RF Systems Division*
> ESTEC*
> Keplerlaan 1, PO Box 299
> NL-2200 AG Noordwijk, The Netherlands_
> _andrea.modenini at esa.int | _www.esa.int_
> <https://urldefense.us/v3/__http://www.esa.int/__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOz9Y62n8$>
> T +31 71 56 53439, M +31 6 484 56 527
> ----- Forwarded by Andrea Modenini/estec/ESA on 11-11-21 08:57 -----
>
> From: "Shames, Peter M\(US 312B\) via CESG-All"
> <cesg-all at mailman.ccsds.org>
> To: "CCSDS Engineering Steering Group - CESG All"
> <cesg-all at mailman.ccsds.org>
> Cc: "EXTERNAL-Pietras, John V\(US 332C-Affiliate\)"
> <john.pietras at gst.com>, "SEA-SA" <sea-sa at mailman.ccsds.org>
> Date: 10-11-21 23:55
> Subject: [Cesg-all] FW: [EXTERNAL] WebEx meeting invitation: SCCS-ARD
> update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
> Sent by: "CESG-All" <cesg-all-bounces at mailman.ccsds.org>
> ------------------------------------------------------------------------
>
>
> Dear CCSDS AD and WG chairs,
>
> The review of the SCCS-ARD has been scheduled for Tuesday, 23 Nov,
> 2021 at 0700 AM PST. The draft of the document, which is in rough,
> “track changes”, form is available on-line. The proposed updates to
> the ABA subsections of sections 4, 5, and 6 (except for the
> security-specific subsections) and posted the draft to the CWE at:
>
> _https://cwe.ccsds.org/sea/docs/SEA-SA/Draft%20Documents/SCCS-ARD-ADD%20Revisions%202020/SCCS-ARD%20draft%20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58_
> <https://urldefense.us/v3/__https:/cwe.ccsds.org/sea/docs/SEA-SA/Draft*20Documents/SCCS-ARD-ADD*20Revisions*202020/SCCS-ARD*20draft*20documents/SCCS-ARD-901x1p1_10-211108.doc?d=wd389d0c8026d47a591fbc35f2e261b58__;JSUlJSU!!PvBDto6Hs4WbVuu7!YAgXpQsrLJbeeQgotEG0WUNrvYYDosRiqy6GyJr5YS38sxD0qn-wbyDWHlnAyZkngUHY_hIq$>
>
> Feel free to download this and review the sections that are of
> interest most interest to you (or all of it if you wish). If there
> are members of your WG who can usefully contribute to this review
> please feel free to invite them as well.
>
> The Space Communications Cross Support Architecture document
> (SCCS-ARD) is a cross-cutting Magenta Book that largely covers the
> SLS, SIS, CSS, and SEA areas and their working groups. We have being
> working on an update to this document that primarily covers what are
> called “ABA” mission configurations, which are those that involve a
> single mission ops center, a single spacecraft, and a ground station.
> The Solar System Internet (SSI) configurations, which involve
> multiple spacecraft, mission centers, and comm assets, and use the DTN
> (or IP) protocols, will be in a future update that builds on this
> foundation.
>
> There have been a number of changes to the CCSDS standards landscape
> since the last edition was published. These include:
>
> * USLP protocol
> * The “VCM suite” of variable coding and modulation standards
> * New CSTS services
> * New Service Management standards
> * Updates to the Synch and Channel coding specs, the liberal approaches
> * New security features in several sections
>
> In addition to these new / updated standards we wish to address the
> following issues as well:
>
> * Improved handling of cross references from the Services viewpoint
> to the protocol stack details (interface binding signatures)
> * Revised section structures and cross referencing
> * Inclusion of “recommended” options and clarification of optional
> and mandatory features
> * Discussion of incomplete / optional capabilities like forward file
> service, handling of details of complexities like MAP service and
> VC/MC multiplexing, COP on the USLP return link, and CADUs in
> FF-CSTS given new Pseudo-randomized “Only Idle Data” (OID) frames
>
> Hope to see you at this review.
>
> Thanks, Peter Shames & John Pietras
>
> *From: *Peter Shames <messenger at webex.com>*
> Reply-To: *Peter Shames <peter.m.shames at jpl.nasa.gov>*
> Date: *Thursday, November 4, 2021 at 3:07 PM*
> To: *Peter Shames <peter.m.shames at jpl.nasa.gov>*
> Subject: *[EXTERNAL] (Forward to others) WebEx meeting invitation:
> SCCS-ARD update review
>
>
> You can forward this invitation to others.
>
>
> Hello,
> Peter Shames invites you to join this WebEx meeting.
>
>
>
> *SCCS-ARD update review*
> Tuesday, November 23, 2021
> 7:00 AM | (UTC-07:00) Pacific Time (US & Canada) | 1 hr 30 mins
>
>
> Meeting number (access code): 2761 585 8804
>
>
> Meeting password: 9JRpYBGHp72
>
>
>
> Join meeting
> <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
>
> *More ways to join:*
>
>
> *Join from the meeting link*
> https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa
> <https://jpl.webex.com/jpl/j.php?MTID=m19aa1606d8ed2742fa89cd2d8d4b0afa>
>
>
>
>
> *Join from a video system or application*
> Dial 27615858804 at jpl.webex.com <%20sip:27615858804 at jpl.webex.com>
> You can also dial 207.182.190.20 and enter your meeting number.
>
>
> *Join by phone*
> +1-510-210-8882 USA Toll
> +44-203-457-5798 U.K. Toll
> Global call-in numbers
> <https://jpl.webex.com/jpl/globalcallin.php?MTID=m5e38422f279e390de6b43d836a8711d0>
>
>
>
>
> *Local: 818-35(4-4044)*
> *Toll Free: 844-JPL-WEBX (844-575-9329)*
>
>
> Can't join the meeting?
>
>
>
> IMPORTANT NOTICE: Please note that this Webex service allows audio and
> other information sent during the session to be recorded, which may be
> discoverable in a legal matter. By joining this session, you
> automatically consent to such recordings. If you do not consent to
> being recorded, discuss your concerns with the host or do not join the
> session.
>
> [attachment "Webex_Meeting.ics" deleted by Andrea Modenini/estec/ESA]
> _______________________________________________
> CESG-All mailing list
> CESG-All at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all
> <https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg-all__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOJm26tok$>
>
> 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-CC mailing list
> SLS-CC at mailman.ccsds.org
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!c_W6kQBKFsU715uHT0ZbEI-Zxyzva6CZAw_475CJiUtC49HEKgcsDEvKn5iiAOkOmu4K-Qo$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-rfm/attachments/20211114/98a366e4/attachment.htm>
More information about the SLS-RFM
mailing list