[Sls-rfm] [EXTERNAL] Re: [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
Tue Nov 30 03:29:52 UTC 2021
Thanks, Peter. I think we will make faster progress with a webex meeting
rather than email. I would like to resolve each of the six comments.
----Jon
*Jon Hamkins*
Chief Technologist, Communications, Tracking, and Radar Division
*O* 818-354-4764 | *M* 626-658-6220
*JPL* | jpl.nasa.gov
On 11/29/2021 3:29 PM, Shames, Peter M (US 312B) wrote:
>
> Hi Jon and all our other SLS C&S and RFM WG colleagues.
>
> In the context of the Space Communication Cross Support (SCCS)
> Architecture Requirements Document (ARD) we have this on-going
> discussion of the state of the SLS “VCM Suite” of variable coding and
> modulation standards. Jon has pointed out, at length, that there is
> no term “VCM suite” defined within the C&S WG or within any of the SLS
> Area literature. I have to agree that this statement, taken by
> itself, is true.
>
> What Jon has then requested is that this term “VCM Suite”, and the
> diagram we have constructed to explain the complexities of this
> situation, be replaced in the SCCS-ARD by the single term “the VCM
> protocol” and also be shown as three separate boxes in figure 6-1,
> Layering of CCSDS link layer protocols.
>
> Last week we held a 2 hour review of all of the major changes we have
> introduced in the SCCS-ARD. These changes are due to the usual 5 year
> document review and the addition of many new standards, several of
> which had only been forecast in the original edition. Among these
> were the DVB-S2 (CCSDS 131.1-B-2), the SCCC (CCSDS 131.2-B-2), and the
> VCM (CCSDS 431.1-B-1). What cannot be in question is that all three
> of these describe themselves as “VCM protocols”. Even the 431.1
> document describes all three of these, separately, as VCM protocols.
>
> See the two attachments for screen shots of the 431.1 document where
> these statements are made and where some of the differences are
> described, in text.
>
> The 431.1-B-1 document also makes this statement, in Sec 1.2 Purpose
> and Scope
>
> The purpose of this Recommended Standard is to specify various
> combinations of coding and modulations in references [1], [2], [4],
> and [5], that can operate under the VCM protocol defined in references
> [2] and [4]. This enables, for example, some of the CCSDS recommended
> channel codes (reference [1]) and modulations (reference [5]) to be
> used with the CCSDS VCM protocol.
>
> In reading through this 431.1-B-1 document, again, I am struck fact
> that the document, in two different sentences, says “there are three
> different VCM protocols”, and then “there is one ‘CCSDS VCM
> protocol’”. Just looking again at these documents, all three of them,
> three things are very clear:
>
> 1. There are three separate documents, each of which is defined as a
> “VCM protocol”.
> 2. The three are similar, but, in detailed fact, are different and
> cannot interoperate.
> 3. The third of these, CCSDS 431.1 cannot stand alone, it is
> meaningless without heavy reliance on major parts of DVB-S2 and
> SCCC, which it terms as Type 1 and Type 2 VCM schemes.
>
> I am not going to un-Earth the history of how we got into this
> situation, but I firmly believe that if we asked any knowledgeable,
> independent, reviewer with relevant technical background to review
> these three standards they would ask “Why do you have three nearly
> identical standards when one would do?”.
>
> But the facts are that we do have two nearly identical standards and a
> third one that could not exist at all without the other two, which it
> is (almost) entirely dependent upon. This is unique in CCSDS.
>
> As for SCCS-ARD, the attached PPT file will make clear how we propose
> to handle this situation. Instead of showing the Telemetry S&C, and
> the Telecommand S&C, and three separate, different, but admittedly
> nearly identical, VCM protocols, we have chosen to call this set of
> triplets the “VCM suite”, to show how these fit with the other related
> standards, and to show their similarities and differences. We think
> that this both provides visibility to this VCM technique, allows us to
> state what value they bring (primarily for high rate downlink
> missions), and also to not overly complicate an already complicated
> diagram with three essentially identical VCM protocols.
>
> We called this trio of VCM standards the “VCM suite”. If you all have
> a better name to suggest we are open to hearing it. All of the other
> people we have had review this agree that this is a suitably simple,
> and effective, way to deal with this complicated situation.
>
> If we need to have a WebEx to discuss this I am more than willing to
> set one up.
>
> Thanks, Peter
>
> *From: *SLS-CC <sls-cc-bounces at mailman.ccsds.org> on behalf of Jon
> Hamkins via SLS-CC <sls-cc at mailman.ccsds.org>
> *Reply-To: *Jon Hamkins <jon.hamkins at jpl.nasa.gov>
> *Date: *Sunday, November 14, 2021 at 11:05 PM
> *To: *Space Link Coding & Synchronization Working Group
> <sls-cc at mailman.ccsds.org>, "sls-rfm at mailman.ccsds.org"
> <sls-rfm at mailman.ccsds.org>, CCSDS Engineering Steering Group - CESG
> All <cesg-all at mailman.ccsds.org>
> *Subject: *[EXTERNAL] Re: [SLS-CC] Fw: WebEx meeting invitation:
> SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
>
> 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> <mailto:cesg-all at mailman.ccsds.org>
> To: "CCSDS Engineering Steering Group - CESG All"
> <cesg-all at mailman.ccsds.org> <mailto:cesg-all at mailman.ccsds.org>
> Cc: "EXTERNAL-Pietras, John V\(US 332C-Affiliate\)"
> <john.pietras at gst.com> <mailto:john.pietras at gst.com>, "SEA-SA"
> <sea-sa at mailman.ccsds.org> <mailto: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>
> <mailto: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>
> <mailto:messenger at webex.com>*
> Reply-To: *Peter Shames <peter.m.shames at jpl.nasa.gov>
> <mailto: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>
> <mailto: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$ <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/20211129/7cc91e12/attachment.htm>
More information about the SLS-RFM
mailing list