[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-cc/attachments/20211114/98a366e4/attachment-0001.htm>


More information about the SLS-CC mailing list