<span style=" font-size:10pt;font-family:sans-serif">Dear John,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
please note that - after internal discussion in SLS
- your observation #! below will be addressed at the forthcoming Spring
Meeting where Jon will provide an input for a VCM Corrigendum to make clearer
the situation.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Your observation
#2 will also be analysed to see whether anything has to be addressed in
the same input paper.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Best regards</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo.</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"John
Pietras" <john.pietras@gst.com></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"sea-sa@mailman.ccsds.org"
<sea-sa@mailman.ccsds.org>, "Jon Hamkins" <jon.hamkins@jpl.nasa.gov>,
"Dudal Clement" <Clement.Dudal@cnes.fr>, "Lee, Dennis
K (332G)" <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int"
<Enrico.Vassallo@esa.int>, "Gilles.Moury@cnes.fr" <Gilles.Moury@cnes.fr>,
"Andrews, Kenneth S(332B)" <Kenneth.S.Andrews@jpl.nasa.gov>,
"Massimo.Bertinelli@esa.int" <Massimo.Bertinelli@esa.int>,
"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">07-04-21
17:51</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">RE:
SLS reply: [Sea-sa] Notes on VCM, DVB-S2, and SCCC</span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Gian
Paolo,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Thanks
for the thoughtful response to my questions. I would like to clarify my
references to CCSDS 415, which I intended to use as an example of something
other than CCSDS 401.0, more than as an explicit target RF & Mod standard.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Until
CCSDS introduced VCM, it was simple and appropriate to align the CCSDS
Sync and Channel Coding (S&CC) and RF & Mod Recommended Standards
with the S&CC Sublayer and Physical Layer (respectively) of the CCSDS
layered model. The </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Conveniently,
in the case of CCSDS 401, both the modulation <b>and</b> RF aspects of
the space Physical Layer <b>are</b> addressed, so that any protocol profile
that places a non-VCM S&CC on top of 401 does indeed address everything,
including the RF requirements needed to produce (as called in CCSDS 231.0)
“Modulated Radio Waveforms”.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">However,
in the case of VCM Type 1* (i.e., SCCC-style VCM), contrary to the depiction
of the VCM protocols corresponding to the full CCSDS Physical Layer, the
recommendations do not address the RF aspects of the Physical Layer. As
you confirmed below, CCSDS 401.0 is normatively cited <b>only</b> with
respect to the modulation definitions. CCSDS 131.2 and 431.1 are mute on
RF requirements. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">[*I
am uncertain about whether this claim also applies to VCM Type 2 (i.e.,
DVB-S2-style VCM). If the DVB-S2 specifications define all of the RF aspects
and those RF aspects are appropriate to civil space applications, then
this is NOT an issue for Type 2 VCM. ]</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">My
use of 415 as a “straw man” alternative was perhaps not the best example.
But what I was attempting to address is that, at least for Type 1 VCM,
there is no indication of the requirements or expectations regarding RF.
I am not an “RF person”, so perhaps the answer is so obvious to any practitioner
in the field that is not necessary to “state the obvious”. However, from
my past protocol work I am used to writing statements about requirements
on “the underlying layer”, and from my SLE/CSTS work I am used to specifying
the requirements on the underlying production process. It seems strange
to me to just leave the RF aspects unaddressed (even by reference) in documents
that are nominally supposed to address them.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Finally,
here are two more observations that I forgot to include in my earlier email:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">1)
CCSDS 131.2-B-1 (<i>Flexible Advanced Coding …</i> ) specifies
that transfer frames be pseudo-randomized before the ASMs are attached
to create CADUs. CADUs are the appropriate term because pseudo-randomization
is applied to the frames. <br>
<br>
CCSDS 431.1-B-1 (VCM Protocol) splits the functionality into “SMTF Stream
Generation” and “VCM Protocol”, but only the VCM Protocol is normatively
addressed. SMTF Stream Generation is only discussed informatively (in section
3.1 – DISCUSSION), where it is described as simply being the attachment
of ASMs directly to the transfer frames to create appropriately-named SMTFs.
In the case of Type 1 VCM using SCCC codes, this ignores the pseudo-randomization
requirement of CCSDS 131.2-B-1. Is that randomization requirement no longer
in effect? If it is in effect, CCSDS 431.1-B-1 should be updated to address
it. Would the randomization requirement apply to only Type 1 VCM using
SCCC, or to Type 1 VCM using TM codes as well? <br>
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">2)
The list of Managed Parameters in CCSDS 431.1 (VCM Protocol)
specifies five managed parameters, CCSDS 131.2-B-1 (SCCC) specifies seven
managed parameters, and CCSDS 131.3-B-1 (CCSDS SLP over DVB-S2) specifies
twelve managed parameters. If CCSDS 431.1 encompasses CCSDS 131.2-B-1 and
CCSDS 131.3-B-1, it seems as though its list of managed parameters should
include more parameters from those other “component” Blue Books (e.g.,
Baseband pulse shaping roll-off factor and Scrambling code number?).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Thanks
again for your consideration of my questions and observations.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">John</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
Gian.Paolo.Calzolari@esa.int [</span><a href=mailto:Gian.Paolo.Calzolari@esa.int><span style=" font-size:11pt;font-family:Calibri">mailto:Gian.Paolo.Calzolari@esa.int</span></a><span style=" font-size:11pt;font-family:Calibri">]
<b><br>
Sent:</b> Tuesday, April 6, 2021 6:43 PM<b><br>
To:</b> John Pietras <john.pietras@gst.com><b><br>
Cc:</b> sea-sa@mailman.ccsds.org; Jon Hamkins <jon.hamkins@jpl.nasa.gov>;
Dudal Clement <Clement.Dudal@cnes.fr>; Lee, Dennis K (332G) <dennis.k.lee@jpl.nasa.gov>;
Enrico.Vassallo@esa.int; Gilles.Moury@cnes.fr; Andrews, Kenneth S(332B)
<Kenneth.S.Andrews@jpl.nasa.gov>; Massimo.Bertinelli@esa.int; Andrea.Modenini@esa.int<b><br>
Subject:</b> SLS reply: [Sea-sa] Notes on VCM, DVB-S2, and SCCC</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">John,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
after some coordination with other SLS
representatives, please find here below mixed in your text (</span><span style=" font-size:10pt;color:red;font-family:Arial"><b>marked
in bold red and starting with >>></b></span><span style=" font-size:10pt;font-family:Arial">).</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Further clarifications may follow.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Best regards</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Gian Paolo</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
PS Please consider that Monday 6 April was a Public Holiday in most of
Europe.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
From: </span><span style=" font-size:9pt;font-family:Arial">"John
Pietras" <</span><a href=mailto:john.pietras@gst.com><span style=" font-size:9pt;color:blue;font-family:Arial"><u>john.pietras@gst.com</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"</span><a href="mailto:sea-sa@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sea-sa@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href="mailto:sea-sa@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sea-sa@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">31-03-21
17:53</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">[Sea-sa]
Notes on VCM, DVB-S2, and SCCC</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:9pt;font-family:Arial">"SEA-SA"
<</span><a href="mailto:sea-sa-bounces@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>sea-sa-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">SEA-SAWG
colleagues ---</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">I’ve
been wading through the <i>Flexible Advanced Coding and Modulation Scheme
for High Rate Telemetry Applications</i> Blue Book (CCSDS 131.2-B-1, March
2012, hereinafter referred to as SCCC [for Serial Concatenated Convolutional
Code]), <i>CCSDS Space Link Protocols Over ETSI DVB-S2 Standard</i> (CCSDS
131.3-B-1, March 2013, hereinafter simply referred to as CCSDS/DVB-S2),
and <i>Variable Code Modulation Protocol</i> (CCSDS 431.1-B-1, February
2021) and comments from reviewers of the ARD table 6-8, trying to understand
the relationships among these various VCM schemes. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">This
email recaps my observations and the questions that my reading has raised.
Ultimately my concern is to be able to represent this area correctly (albeit
abstractly) in the SCCS-ARD. I would very much appreciate any feedback
about the correctness of my interpretations.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
SLS do appreciate do appreciate your concern to correctly represent this.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">A.
SCCC (CCSDS 131.2-B-1, March 2012)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">The
SCCC protocol stack diagram (figure 2-1) indicates the it covers
the CCSDS Sync and Channel Coding Sublayer and the Physical Layer:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_1_0F6312380F630E2800307012C12586B9 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">An
introductory paragraph that precedes this diagram states “The Synchronization
and Channel Coding Sublayer provides methods of</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">synchronization
and channel coding for transferring Transfer Frames over a space link while
the Physical Layer provides the RF and modulation methods for transferring
a stream of bits over a space link in a single direction.”</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">However,
the SCCC specification addresses only some aspects of the Physical Layer
- specification of the five modulation schemes to be used as part
of SCCC:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">1)
QPSK (specified by cross reference to the appropriate definition
in CCSDS 401.0):</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">2)
8PSK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">3)
16APSK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">4)
32APSK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">5)
64APSK</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">and
coding rates.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">The
“RF” aspects of the Physical Layer of a space link (frequency bands,
polarization, etc., etc.) are not mentioned at all. So the protocol stack
diagram is at least partially misrepresentative. There should be another
“RF Physical sublayer” under the <i>Flexible Advanced Coding and Modulation
Scheme for High Rate Telemetry Applications</i> “layer”. But this raises
another issue – what CCSDS Blue Books (or what parts of what CCSDS Blue
Books) would constitute such an RF Physical sublayer? CCSDS 401.0 is referenced,
but only with respect to the specification of QPSK modulation. Is it assumed
that 401.0 supplies the underlying RF functions? CCSDS also has CCSDS 415.1
(<i>Data Transmission and PN Ranging for 2 GHz CDMA Link via Data Relay
Satellite</i>) – is SCCC viable for use over 415.1 links? [Note – the
SCCS-ARD does not include CCSDS 415.1 because it is currently used only
for the NASA TDRSS-based Space Network. But the authors of the SCCC book
should not ignore the implications for use of SCCC over something other
than 401.0, and how to address such possible wider usage in the SCCC blue
book.]</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Indeed 401.0-B ( </b></span><a href="https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.ccsds.org%2FPubs%2F401x0b31.pdf&data=04%7C01%7Cjohn.pietras%40gst.com%7Cb7448a0473974ee7623808d8f94d6683%7C17917f83951e48839dd6b11685623b38%7C1%7C0%7C637533458127636936%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YRis4GezmVt1wc%2B%2BRfwT0o45lsOdiinZC8qu8W0TuZo%3D&reserved=0"><span style=" font-size:12pt;color:blue;font-family:Calibri"><b><u>https://public.ccsds.org/Pubs/401x0b31.pdf</u></b></span></a><span style=" font-size:12pt;color:red;font-family:Calibri"><b>
) contains other regulations in addition to modulations. This is visible
in section 1.4 DOCUMENT FORMAT. By convention those other conventions are
never mentioned explicitly in the standards referring to 401.0-B. It is
clear that modulations are not used ignoring the rest of the regulations
and this is considered implicit and it has never given implementation problems.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
SCCC in NOT intended for use over 415.1 links. In fact, that book is not
mentioned in SCCC.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Some
other observations:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">a)
The book – written in 2012 – normatively references only
the TM and AOS space data link protocols. SCCC depends on the use of the
Frame Error Control Field (as defined in the TM and AOS SDLPs) to perform
Frame Validation. SCCC is also expected to be used to carry fixed-length
USLP frames, so USLP (at least the specification of the FECF in the USLP
frame) is normative on the SCCC. </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
SCCC is going to add USLP Frames and the normative references will be listed
together with TM SDLP and AOS. Andrea Modeninini as book Editor is preparing
the relevant draft.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">b)
In section 2.3 (Internal Organization), the document describes
the Sending End (section 2.3.1) using diagrams of the individual functions
involved and the “stream format at different stages of process”. However,
the description of the Receiving End (2.3.2) consists of “At the receiving
end, the Synchronization and Channel Coding Sublayer accepts a continuous
and contiguous stream of physical channel symbols, performs functions selected
for the mission, and delivers Transfer Frames to the Data Link Protocol
Sublayer.” Besides saying nothing about how this is done, this description
is inconsistent with the declared scope of SCCC as performing functions
in in the Physical Layer as well as the Synchronization and Channel Coding
Sublayer. </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
In a few cases some remarks on the receiving side are mentioned when relevant,
however, specification of receivers is not part of our standards. The output
at the sending side shall be unique while at the receiving side several
algorithm can be used to correctty process the received stream. This is
valid for decoding, demodulation, decompression, decrypt, etc. >>>
However you are correct, the book will mention that also the receiving
side performs functions in in the Physical Layer and in the Synchronization
and Channel Coding Sublayer. </b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">c)
Section 7.1.1 states “Frame synchronization is necessary
for subsequent processing of the Transfer Frames. Furthermore, it is necessary
for synchronization of the pseudo-random generator, <i>if used</i> (see
section 8).} [italicization mine]. Section 8.1 states “The Pseudo-Randomizer
defined in reference [1] is always required by SCCC”. The “if used”
qualifier in 7.1.1 seems superfluous since 8.1 says that it must be used,
and could lead to misunderstanding that randomization might be optional.
</span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Andrea Modeninini as book Editor is preparing the relevant draft and will
take of this editorial improvement.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">d)
This is a nit-pick, but the acronyms “PSK”, “QPSK”, and
“APSK” are never spelled out or listed in the acronym list. I already
knew what “PSK” and “QPSK” stood for, but had to Google “APSK” to
get “amplitude and phase shift keying”. </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Andrea Modeninini as book Editor is preparing the relevant draft and will
take of this editorial improvement together with Tom Gannett for completing
the list of acronyms.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">I
see from the CCSDS Framework that an update to this document is underway.
Perhaps these comments will be useful to the C&S WG.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">B.
CCSDS/DVB-S2 (CCSDS 131.3-B-1, March 2013)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">The
following figure is presented in the Blue Book to relate the functions
defined in the CCSDS/DVB-S2 Blue Book to the OIS and CCSDS layered models:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_1_0F620DD40F620B6800307012C12586B9 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Other
than the relatively-simple “CADU Stream Generation” sublayer, the great
majority of the functionality of this book is specified by reference to
the DVB-S2 specification that was in effect as of the time of specification
of this Recommended Standard, which is given in the normative References
as</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">[1]
<i>Digital Video Broadcasting (DVB); Second Generation Framing Structure,
ChannelCoding and Modulation Systems for Broadcasting, Interactive Services,
News Gathering and other Broadband Satellite Applications</i>. ETSI EN
302 307 V1.2.1<i> </i>(2009-08). Sophia-Antipolis: ETSI, 2009.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">NOTE
– ETSI standards are available for free download at </span><a href="https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.etsi.org%2F&data=04%7C01%7Cjohn.pietras%40gst.com%7Cb7448a0473974ee7623808d8f94d6683%7C17917f83951e48839dd6b11685623b38%7C1%7C0%7C637533458127646928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oqb1o%2B%2Bt6s6tGyfPS7cejjQbirekhC7ACYOhbu9426Q%3D&reserved=0"><span style=" font-size:12pt;color:blue;font-family:Calibri"><u>http://www.etsi.org</u></span></a><span style=" font-size:12pt;font-family:Calibri">.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">In
attempting to use the link to obtain a copy of the document, I searched
on the document number (ETSI EN 302 307 V1.2.1). There was no document
with this number available, but three with variations on the number: </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
DVB-S2: ETSI EN 302 307 V1.3.1 (2013-03),</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
DVB-S2, Part1, DVB-S2: ETSI EN 302 307-1 V1.4.1
(2014-11), and </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
DVB-S2, Part2, DVB-S2 Extensions: ETSI EN 302
307-2 V1.2.1 (2020-08). </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">My
interpretation is that the Part 1 (2014) and Part 2 (2020) versions are
replacements for the 2008 and 2013 DVB-S2 (no parts) version and update
(respectively), although the documents don’t say that in so many words.
Without a better understanding of the applicable technologies, I am unable
to determine (or even guess) which Parts (1, 2, or both) are applicable
to the use of DVB-S2 for the encoding and transmission of CCSDS SDLP frames.
</span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
CNES has prepared an updated document that should start soon Agency Review.
The CMC Approval versuon still refernces ETSI EN 302 307 V1.2.1.
I think that the standard is really intended for use with V1.2.1 and not
with later versions.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">I
am unable to say for certain, but it also appears that neither the Part
1 nor the Part 2 specifications address complete set of RF requirements
to a level similar to that found in CCSDS 401.0. If my impression is correct
in this respect, as with the SCCC book it is somewhat incorrect to imply
that the DVB-S2 specifications address all aspects of the Physical Layer,
as is implied by Figure 2-1 (copied above). Again, should there be some
“RF Physical sublayer” under the DVD-S2 transmission sublayer? And if
so, are some subset of functions defined in CCSDS 401.0 assumed to satisfy
the requirements for that RF Physical sublayer? What about DVB-S2 “over”
CCSDS 415.1 links?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Please consider the SCCC reply above for 401.0-B. </b></span><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">C.
VCM Protocol (CCSDS 431.1-B-1, February 2021)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Figure
2-1 of the VCM Protocol Blue Book is:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><img src=cid:_1_0F66A3A40F66A13800307012C12586B9 style="border:0px solid;"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Note
that the “SMTF Stream Generation” function/sublayer is exactly the same
as the “CADU Stream Generation” function/sublayer of the CCSDS/DVB-S2
Blue Book: “SMTF” is the more-appropriate term for a transfer frame that
is pre-pended with an ASM, whereas “CADU” in general allows the possibility
of intermediate encoding being applied before the ASM. </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
C&S WG may consider using a uniform term. Andrea & Ken may consider
thois point of discussion.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Regarding
the VCM Protocol itself, the blue book specifies three sets of “modes”:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
Modes that apply to CCSDS Turbo and LDPC encoding
(a subset of, and as defined in, CCSDS 131.0-B). These are the “TM” codes;</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
Modes that apply to SCCC encoding. These modes
are “consistent with the existing specification of codes, modulations,
and VCM protocol given in references [2] [SCCC Blue Book] and [5] [CCSDS
401.0]”; and</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">-
Modes that apply to CCSDS DVB-S2 encoding. These
mode are “consistent with the existing specification of codes, modulations,
and VCM protocol given in references [3] [CCSDS/DVB-S2], [4] [the <i>2014
version</i> of DVB-S2: Part 2], and [5] [CCSDS 401.0]”.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Type
2 VCM has a set of modes that apply to CCSDS Turbo and LDPC coding schemes
(as defined in CCSDS 131.0-B) and a different set of codes for DVB-S2.
The difference between Type 1 and </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">The
VCM BB defines two VCM protocol “Types”: Type 1 and Type 2. The two Types
differ in the values for the parameters H (the length of the PLFRAME header,
S (the number of codeword modulation symbols between pilot symbol blocks),
and P (the number of modulation symbols present in each optional symbol
block). Type 1 uses the H/S/P values that have already been defined in
the SCCC Blue Book, and Type 2 uses the H/S/P values that have already
been defined in the CCSDS/DVB-S2 Blue Book and the ETSI DVB-S2: Part 2
standard.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">What
the VCM Blue Book specifies <i>uniquely</i> is the use of TM Turbo and
LDPC encoding, which is defined for both VCM Type 1 and VCM Type 2. However,
the material regarding SCCC encoding and DVB-S2 encoding appears to me
to be simply a restatement of existing material that is already normatively
stated in the SCCC Blue Book, CCSDS/DVB-S2 Blue Book, and the ETSI DVB-S2:
Part 2 standard. Is there is something that the VCM Protocol BB adds to
the existing standards? </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
The 431.1-B VCM standard does not alter the specification of the
131.2-B and 131.3-B VCM protocols. This means that a user of SCCC or DVB-S2
codes compliant with 131.2-B or 131.3-B will also comply with 431.1-B.
The 431.1-B book puts the VCM protocol under a common umbrella to help
explain how to use TM codes with either of the SCCC or DVB-S2 approaches
to VCM. This has the side benefit of showing that there really is one common
VCM approach in CCSDS..</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">The
fact that the VCM Protocol book restates and in a sense co-opts the SCCC
and CCSDS/DVB-S2 Blue Books can lead to ambiguity. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
This situation is no different than the 401.0-B incorporating the
definitions of the higher order modulations which are already described
in 131.2-B and 131.3-B. They are the same, so there is no ambiguity.</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">When
one refers to “CCSDS VCM”, should that be interpreted as a blanket reference
to “TM VCM”, SCCC VCM, and DVB-S2 VCM, or do we want to continue to cull
out the different flavors separately? For the purposes of the SCCS-ARD,
we might want to just use “CCSDS VCM” to collectively refer to all flavors,
with a single reference to CCSDS 431.1, and have a separate (simple, high-level)
“discussion” of the components of that collective protocol. That will
certainly make the tables in the ARD simpler.<b> </b></span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Agreed. There really is only one approach to VCM in CCSDS. OK for SCCS-ARD
to just use “CCSDS VCM” to collectively refer to all flavors. However
referincg may better include all the books for those willing to look at
the details .</b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b> </b></span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Finally,
as with the SCCC and CCSDS/DVB-S2 blue books, the VCM Protocol Blue Book
does not address the RF aspects of the Physical Layer. The same questions
apply about whether an RF Physical sublayer should be called out, whether
and what aspects of CCSDS 401.0 meet the requirements for such a sublayer,
and whether other space link physical layer specifications (such as CCSDS
415) can be used for VCM. </span><span style=" font-size:12pt;color:red;font-family:Calibri"><b>>>>
Please consider the SCCC reply above for 401.0-B. </b></span><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">John</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>
SEA-SA mailing list</span><span style=" font-size:10pt;color:blue;font-family:Courier New"><u><br>
</u></span><a href="mailto:SEA-SA@mailman.ccsds.org"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>SEA-SA@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u><br>
</u></span><a href="https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsea-sa&data=04%7C01%7Cjohn.pietras%40gst.com%7Cb7448a0473974ee7623808d8f94d6683%7C17917f83951e48839dd6b11685623b38%7C1%7C0%7C637533458127646928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=29oNZ2bpK28DR0O44Td4ntyNnAoo6%2B1sRdzscp%2Bsmbw%3D&reserved=0"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</u></span></a></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">This
message is intended only for the recipient(s) named above. It may contain
proprietary information and/or</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">protected
content. Any unauthorised disclosure, use, retention or dissemination is
prohibited. If you have received</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">this
e-mail in error, please notify the sender immediately. ESA applies appropriate
organisational measures to protect</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">personal
data, in case of data privacy queries, please contact the ESA Data Protection
Officer (</span><a href=mailto:dpo@esa.int><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>dpo@esa.int</u></span></a><span style=" font-size:10pt;font-family:Courier New">).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<PRE>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@esa.int).
</PRE>