[SLS-CC] [EXTERNAL] Re: Fw: WebEx meeting invitation: SCCS-ARD update review scheduled for Tuesday, 23 Nov, 2021 at 0700 AM PST
Shames, Peter M (US 312B)
peter.m.shames at jpl.nasa.gov
Mon Nov 29 23:29:07 UTC 2021
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"
* 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.
* Recommendation: Remove this phrase in all places and replace with "the VCM protocol."
* 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.
* Description: Table 6-1 lists three references for the VCM "Suite": 131.2, 131.3, and 431.1.
* 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.
* 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".
* Description: The table has a left-column heading labeled "Space-to-Ground Links."
* Recommendation:
* Remove or reword "Space-to-Ground Links"
* 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
* 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.
* 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.
* 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
* 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
* 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.
* 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
* Description. The figure purports to show component standards of "the VCM suite."
* Recommendation:
* Remove this figure from the SCCS-ARD.
* 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<mailto: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<mailto: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
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<mailto: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<mailto:dpo at esa.int>).
_______________________________________________
SLS-CC mailing list
SLS-CC at mailman.ccsds.org<mailto: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-cc/attachments/20211129/1b4f97cd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SCCC & DVB each specify
Type: application/pdf
Size: 500400 bytes
Desc: SCCC & DVB each specify
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20211129/1b4f97cd/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DVB & SCCC differences.pdf
Type: application/pdf
Size: 559417 bytes
Desc: DVB & SCCC differences.pdf
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20211129/1b4f97cd/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2021-11-29 SCCS-ARD VCM Fig 6-2.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 1135260 bytes
Desc: 2021-11-29 SCCS-ARD VCM Fig 6-2.pptx
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20211129/1b4f97cd/attachment-0001.pptx>
More information about the SLS-CC
mailing list