<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Dear Gippo,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In this, as in many other things, one man’s noise is another man’s signal. I was just on a WebEx with Erik and his crew about the Functional Resource Model, what it does, how it must be maintained, and the processes around that. One topic
that came up is that the FRM must look across all of SLS, SIS, CSS, and parts of SEA. In order to build this model they must understand, in depth, all of these standards, their functions, and how they interconnect. In doing that they have had to confront
this same issue of “does Tab A fit into Slot B?”. And they too have identified issues.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One way to look at this is as a sort of V&V exercise, and it may very well result in the FRM team pointing issues out to the WGs in these other Areas. Interestingly enough, there is the converse aspect, where these other Areas and WGs
will need to do V&V on the FRM to ensure that it is accurate. In fact, this sort of V&V is really a part of the responsibility of all of the ADs and the CESG, but we do not always do it perfectly, or to the needed level of detail to really be truly useful
as a V&V function.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m of the opinion that this sort of in depth evaluation and cross check is very useful. You may feel otherwise, but it is work that CCSDS has agreed should be done and asked us to do. Let’s see if we can find a way to make this work
to the benefit of all of us. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Our users will surely benefit.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Maxime respicit, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><br>
<b>Date: </b>Wednesday, April 21, 2021 at 4:26 AM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, Dudal Clement <Clement.Dudal@cnes.fr>, Dennis K Lee <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, Gilles Moury <Gilles.Moury@cnes.fr>, John Pietras <john.pietras@gst.com>,
Jon Hamkins <jon.hamkins@jpl.nasa.gov>, Kenneth Andrews <kenneth.s.andrews@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><br>
<b>Subject: </b>Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Peter,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> I want to be short.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I do not </span>question the value of this document<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> but...
</span><i><span style="font-size:12.0pt">est modus in rebus.</span></i><span style="font-size:12.0pt">
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Making this document more normative that the mentioned blue books (as it appears from your remarks) is not going in the right direction IMO.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Best regards</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Gian Paolo</span> <br>
<br>
<br>
<br>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Gian.Paolo.Calzolari@esa.int" <Gian.Paolo.Calzolari@esa.int></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, "Dudal Clement" <Clement.Dudal@cnes.fr>, "Lee, Dennis
K (US 332G)" <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, "Gilles.Moury@cnes.fr" <Gilles.Moury@cnes.fr>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com>, "Hamkins, Jon (US 3300)" <jon.hamkins@jpl.nasa.gov>,
"Andrews, Kenneth S (US 332B)" <kenneth.s.andrews@jpl.nasa.gov>, "sea-sa@mailman.ccsds.org" <sea-sa@mailman.ccsds.org></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">13-04-21 22:20</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p style="margin:0in">Hi Gippo,<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">I’m sorry if you misunderstand the intent, and no, we are not, as Nestor sometimes suggested “Trying to be more Catholic than the Pope.” What we are trying to do is to provide guidance for the users of CCSDS standards as to how “Tab A
fits into Slot B”. In the process of trying to do that in a way that is understandable we have encountered all sorts of special cases, “if this, then not that”, “only in this case, not in that case”, and special dispensations. We did not make these things
up, we read the docs and discovered them. And so we are asking you guys for cross-checks “did we understand this correctly?” and in some cases for clarifications, as in “can we say this differently to be clearer?”.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">I believe that you understand that while this is a “space communication cross support architecture” that it is not now, and never has been, just about “cross support” in any narrow sense. It has always covered four of the six CCSDS Areas
of work: SLS, SIS, CSS, and SEA. And it is about mission systems (EUN) to ground station (ESLT), and from ground station (ESLT) to spacecraft (SUN), for basic “single space link” or ABA missions and for more complex, internetworked or relayed architectures
(SSI). This is “cross support” in the broadest, end-to-end, sense, including security considerations.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">We all have our own points of view, and they differ. That, as they say, is what makes a horse race. I do have to be amused that the one “oh yes, this doesn’t work” topic for FF-CSTS is precisely, from my point of view, the only reason
why we really needed FF-CSTS in the first place. That was to provide coding in the ESLT for a stream of frames, and the “plumbing” to merge (and then encode) multiple streams of frames in the ESLT. Without those features, and the related coding for uplink
/ forward AOS and USLP, we really did not need to invest in creating FF-CSTS at all. Not having this is not just “some limitation”, it is the raison d’etre for FF-CSTS.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">It does remain to this architecture document to describe how all of these many parts fit together. And some of these parts, as you know, don’t fit particularly well, or it’s like a jigsaw puzzle with some missing pieces, others that need
to be filed down a bit to fit, and others where there are three or more mostly identical pieces that sort of all fit the same … mostly. There is no other single place in CCSDS where you can find the sort of integrated views of this broad collection of information
that the SCCS-ARD provides. <o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">I really do not know why you would question the value of this document, but, of course, this is my own opinion and perception.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">Cheers, Peter<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt">From: </span></b><span style="font-size:12.0pt">Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Friday, April 9, 2021 at 3:41 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, Dudal Clement <Clement.Dudal@cnes.fr>, Dennis K Lee <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, Gilles Moury <Gilles.Moury@cnes.fr>, John Pietras <john.pietras@gst.com>,
Jon Hamkins <jon.hamkins@jpl.nasa.gov>, Kenneth Andrews <kenneth.s.andrews@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><b><br>
Subject: </b>Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span><o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Peter,</span>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
frankly speaking I am quite puzzled by this kind of inquiring.</span> <o:p>
</o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">It looks as you want to go to a level of detail even bigger than 401.0-B instead of simply referencing that book</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">This is giving me a strange (and uncomfortable) perception (*) like you want either rewrite 401.0-B or teach RFM WG how to write it.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">(*) perception is clearly something personal..</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif">
</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">If you think that a new
</span><span style="font-size:12.0pt">“RF Physical Sublayer” </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">is really required together with other "corrections" to that book, I strongly recommend you address all that to the RFM WG in the
form of a formal input paper (you may still be on time for Spring 2021 Meetings).</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">On my side I am really puzzled by the level of details you want to enter in your document, specially considering the focus on cross support services where (just to say something
also with respect to available cross support service) I think we can easily affirm as a matter of fact that</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">- SLE RAF can be used with any of the three 131.x standards</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">- SLE RCF can be used with any of the three 131.x standards</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">- SLE ROCF can be used with any of the three 131.x standards</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">- SLE CLTU can be used ONLY with TC Coding</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">- CSTS Forward Frame can be used with 231.0 (TC) standards and it can be used with any of the three 131.x standards (*)</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">(*) only exception I understand should be some imitation for the "FF-CSTS Provider (CADUs)" with respect to the coding options performing encoding of SMTF streams</span><o:p></o:p></p>
<p style="margin:0in"><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
It looks as there is an attempt of having an architecture document more normative than the normative standards. Is this really a good idea?</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Of course this is my personal perception and opinion.</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Best regards</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Gian Paolo</span> <br>
<br>
<br>
<br>
<br>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
To: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Gian.Paolo.Calzolari@esa.int" <Gian.Paolo.Calzolari@esa.int></span>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Cc: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, "Dudal Clement" <Clement.Dudal@cnes.fr>, "Lee, Dennis K (US 332G)" <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>,
"Gilles.Moury@cnes.fr" <Gilles.Moury@cnes.fr>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com>, "Hamkins, Jon (US 3300)" <jon.hamkins@jpl.nasa.gov>, "Andrews, Kenneth S (US 332B)" <kenneth.s.andrews@jpl.nasa.gov>, "sea-sa@mailman.ccsds.org"
<sea-sa@mailman.ccsds.org></span> <span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">
<br>
Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">07-04-21 20:54</span>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:2.5in;margin-left:0in">
<o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Hi Gippo,</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">I understand now that you meant the reference to be to the 401.0 BB and not to dismiss the 415.1 reference. Thanks.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">But I still do not think that the highlighted paragraph addresses the specific aspect of the questions that John raised:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">“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?”</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">As we understand it, the RF&M document, the 401.0 BB, includes aspects that address modulations, data rates (coded symbol rates), frequencies, and directions, as well as aspects covered by regulations (ITU),
conventional usages, and even implementation constraints. As such there are really separate ISO BRM Layer 1 “sub-layers” that are being addressed. Modulation is the most obvious one, but these other “sub-layers”, or aspects, play a strong part in the complexity
of the 401.0 spec which tends to be narrowly parsed into segments like:</span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt">2.4.18 MODULATION METHODS AT HIGH CODED SYMBOL RATE TRANSMISSIONS, EARTH EXPLORATION SATELLITES (EES) 8 GHZ BAND, SPACE-TO-EARTH
</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">This addresses, very narrowly, a specific frequency band (8 GHz), a class of spacecraft (EES), a direction (Space-to-Earth), and a specific subset (HOM) of all the possible modulations. As you all know,
this is only one of many such narrowly parsed segments. We know that there are technical as well as regulations, conventions, and technical limitations that motivate this particular construction of this standard.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">But here is the underlying question that John’s “all aspects of the Physical Layer” question was trying to get at. Is it correct to state that SCCC, or DVB, just can use all of the possible 401.0 modulations,
frequency bands, data rates, and directions, or is it only a sub-set of them? In particular, with DVB-S2, which was designed for near Earth high-rate, downlink from HEO satellites, is it accurate to just state “it can use all of the 401.0 defined modulations,
etc”? Or do the DVB and SCCC VCM approaches really assume something else, or state something else in terms of their expectations as to which parts of the 401.0 book are applicable? Which frequencies, data rates, and directions? We were not able to find
these linkages, but maybe we were just not looking in the right places.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">In terms of how to diagram the relationships between the VCM books, as a set, and the 401.0 book it also occurred to us that the references to the RFM book, in the context of VCM, is sort of like referencing
specific parts, of parts, of the 401.0 book from <b><i>inside</i></b> the VCM books. It appears that there is a part of the 401.0 book that is inside the CODMOD pairs in the VCM spec and a part of it that is in a sense
<b><i>outside</i></b> the CODMOD VCM spec, in the FM & FD “layer”. So in some ways the 401.0 book is “inside” the VCMs and not “under” them. This seems almost analogous to the sort of “tunneling” constructs that sometimes show up in network layer constructs
with the use of VPNs, or when BP is tunneled in IP. Those are “network layer inside network layer”. There is a certain set of more or less “standard” configurations and others that are not normally used.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">All of these questions came up as we were reading through this set of documents and trying to “connect all of the dots”. Similar sorts of questions arose when thinking through the question of how to do ranging,
and Delta-DOR, with the Higher Order Modulations (HOM) that are featured in SCCC and DVB, and also now in the VCM and 401.0 books. </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">We think some clear statements to disambiguate all of this will be very useful to the readers of the SCCS-ARD and the documents it references.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Is the basis for this question more clear now? Perhaps that reference to “RF Physical Sublayer” was too vague?</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Thanks, Peter</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt">From: </span></b><span style="font-size:12.0pt">Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Tuesday, April 6, 2021 at 11:14 PM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>"Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, Dudal Clement <Clement.Dudal@cnes.fr>, Dennis K Lee <dennis.k.lee@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, Gilles Moury <Gilles.Moury@cnes.fr>, John Pietras <john.pietras@gst.com>,
Jon Hamkins <jon.hamkins@jpl.nasa.gov>, Kenneth Andrews <kenneth.s.andrews@jpl.nasa.gov>, SEA-SA <sea-sa@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Peter,</span><span style="font-size:12.0pt">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
just a quick clarification.</span><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">In a few places where it is stated:
</span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Please consider the SCCC reply above for 401.0-B</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">as the statement
</span><span style="font-size:12.0pt"> “<b><span style="color:red">>>> SCCC in NOT intended for use over 415.1 links. In fact, that book is not mentioned in SCCC.</span></b></span><span style="font-size:10.0pt;font-family:"Arial",sans-serif">" refers to 415.1
and not to 401.0-B, the correct reference is the following one</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
----------------------</span><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Indeed 401.0-B (
</span></b><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/401x0b31.pdf__;!!PvBDto6Hs4WbVuu7!efnnGUGob28wvg7EItHJSV1crsjHcx6eUUB7Tj84uTdExGvhIl9lcemPsL5rx4hl3oReM1oG$"><b><span style="font-size:12.0pt">https://public.ccsds.org/Pubs/401x0b31.pdf</span></b></a><b><span style="font-size:12.0pt;color:red">
) 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.</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
----------------------</span><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
You may want to review your other assertions below according to this.</span><span style="font-size:12.0pt">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
I guess this will help everybody and specially the SLS readers.</span><span style="font-size:12.0pt">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
Best regards</span><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
Gian Paolo</span><span style="font-size:12.0pt"> <br>
<br>
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
<br>
From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
To: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Gian.Paolo.Calzolari@esa.int" <Gian.Paolo.Calzolari@esa.int>, "EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras@gst.com></span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Cc: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Dudal Clement" <Clement.Dudal@cnes.fr>, "Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, "Lee, Dennis K (US 332G)" <dennis.k.lee@jpl.nasa.gov>, "Hamkins, Jon (US 3300)" <jon.hamkins@jpl.nasa.gov>,
"Gilles.Moury@cnes.fr" <Gilles.Moury@cnes.fr>, "Andrews, Kenneth S (US 332B)" <kenneth.s.andrews@jpl.nasa.gov>, "Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, "sea-sa@mailman.ccsds.org" <sea-sa@mailman.ccsds.org></span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">07-04-21 01:47</span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [EXTERNAL] [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span><span style="font-size:12.0pt">
</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Hi Gippo,</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Thanks for the replies. It is helpful to keep up this collegial dialogue as we try and sort out the complexities. John may have some comments of his own, and I have some materials from our SEA-SA meeting
of yesterday that I will share with all of you once I send this brief note off.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">In a few places you stated:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Please consider the SCCC reply above for 401.0-B</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">I am puzzled by some of these references. If you mean only to point to the statement “<b><span style="color:red">>>> SCCC in NOT intended for use over 415.1 links. In fact, that book is not mentioned in
SCCC.” </span></b>then this reference makes sense. We understand that the 415.1 spec is rather a “stand-alone” standard. It is not clear that we even need to include it in this document unless there is a strong requirement to do so.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">For the others: </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Please consider the SCCC reply above for 401.0-B.
</span></b><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">I think that this “reply for 401.0-B” is only relevant to the 415.1 part of this, and not to the rest of this statement relating to the relationships between the SCCC and the physical sub-layer aspects of
the 401.0 spec. </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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.
<b><span style="color:red">>>> Please consider the SCCC reply above for 401.0-B. </span>
</b> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Here too, I believe that the 415.1 part of this is accurate, but that this leave unanswered the question about the relationships between DVB and the physical sub-layer aspects of the 401.0 spec. . The
401.0 spec, as you are aware, is a thicket of “if this, then that, but not that” kinds of statements. And it has finely parsed clauses about specific frequency bands, modulations, data rates, ranging (or not), and directionality. And SCCC (and DVB) both
include 401.0 modulations and somehow subsume them inside the frame of pilot symbols. It’s not clear from either the SCCC or DVB specs just which of the possible physical sub-layer and directionality parts of the 401.0 spec are applicable. </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Can you and your SLS Area team help to clarify these questions?</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">In the context of the 431.0 spec, and its relationship to SCCC and DVB, this occurs:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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?
<b><span style="color:red">>>> 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..</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">I agree that the 431.0 spec puts all three of the related VCM options under one umbrella, and that this helps the reader to understand the similarities, and differences, among these protocols stacks. And
it appears to be the case that a use of SCCC or DVB will, because of the structure of this document, be compliant with the 431.0 spec. That said, it is also true that an implementation of SCCC will not be compliant with DVB, nor will an implementation of
DVB be compliant with SCCC, nor, for that matter, with the one using the CCSDS TM code options. There is not really “one common VCM approach” in CCSDS, there are three, with some complex overlaps and interconnections that this book helps to clarify, but cannot
dispel.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">We do hope to add just enough clarifying material in the SCCS-ARD to make this as clear as we can. And we will need you help to ensure that this is as clear as it can be. Please look at the next set of
materials I will send and let us know what you think.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Thanks, Peter</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt">From: </span></b><span style="font-size:12.0pt">SEA-SA <sea-sa-bounces@mailman.ccsds.org> on behalf of Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Tuesday, April 6, 2021 at 3:43 PM<b><br>
To: </b>John Pietras <john.pietras@gst.com><b><br>
Cc: </b>Dudal Clement <Clement.Dudal@cnes.fr>, "Andrea.Modenini@esa.int" <Andrea.Modenini@esa.int>, Dennis K Lee <dennis.k.lee@jpl.nasa.gov>, Jon Hamkins <jon.hamkins@jpl.nasa.gov>, Gilles Moury <Gilles.Moury@cnes.fr>, Kenneth Andrews <kenneth.s.andrews@jpl.nasa.gov>,
"Enrico.Vassallo@esa.int" <Enrico.Vassallo@esa.int>, SEA-SA <sea-sa@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">John,</span><span style="font-size:12.0pt">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
after some coordination with other SLS representatives, please find here below mixed in your text (<b><span style="color:red">marked in bold red and starting with >>></span></b>).</span><span style="font-size:12.0pt">
</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
Further clarifications may follow.</span><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
Best regards</span><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
Gian Paolo</span><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
<br>
PS Please consider that Monday 6 April was a Public Holiday in most of Europe.</span><span style="font-size:12.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
<br>
<br>
From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"John Pietras" <john.pietras@gst.com></span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
To: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"sea-sa@mailman.ccsds.org" <sea-sa@mailman.ccsds.org></span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">31-03-21 17:53</span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">[Sea-sa] Notes on VCM, DVB-S2, and SCCC</span><span style="font-size:12.0pt">
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Sent by: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"SEA-SA" <sea-sa-bounces@mailman.ccsds.org></span><span style="font-size:12.0pt">
</span><o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<span style="font-size:12.0pt"> </span> <o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">SEA-SAWG colleagues ---</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> SLS do appreciate do appreciate your concern to correctly represent this.</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">A. SCCC (CCSDS 131.2-B-1, March 2012)</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">The SCCC protocol stack diagram (figure 2-1) indicates the it covers the CCSDS Sync and Channel Coding Sublayer and the Physical Layer:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><img border="0" width="610" height="379" style="width:6.3541in;height:3.9479in" id="_x0000_i1027" src="cid:image001.gif@01D7368F.B3BD7480"><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">An introductory paragraph that precedes this diagram states “The Synchronization and Channel Coding Sublayer provides methods of</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">1) QPSK (specified by cross reference to the appropriate definition in CCSDS 401.0):</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">2) 8PSK</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">3) 16APSK</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">4) 32APSK</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">5) 64APSK</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">and coding rates.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Indeed 401.0-B (
</span></b><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/401x0b31.pdf__;!!PvBDto6Hs4WbVuu7!efnnGUGob28wvg7EItHJSV1crsjHcx6eUUB7Tj84uTdExGvhIl9lcemPsL5rx4hl3oReM1oG$"><b><span style="font-size:12.0pt">https://public.ccsds.org/Pubs/401x0b31.pdf</span></b></a><b><span style="font-size:12.0pt;color:red">
) 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.</span></b><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> SCCC in NOT intended for use over 415.1 links. In fact, that book is not mentioned in SCCC.</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Some other observations:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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.
<b><span style="color:red">>>> 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.</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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. <b><span style="color:red">>>> 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.
</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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. <b><span style="color:red">>>> Andrea Modeninini as book Editor is preparing the relevant draft and will take of this editorial improvement.</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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”. <b><span style="color:red">>>> 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.</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">B. CCSDS/DVB-S2 (CCSDS 131.3-B-1, March 2013)</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><img border="0" width="474" height="322" style="width:4.9375in;height:3.3541in" id="_x0000_i1026" src="cid:image002.gif@01D7368F.B3BD7480"><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">[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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">NOTE – ETSI standards are available for free download at
</span><a href="https://urldefense.us/v3/__http:/www.etsi.org/__;!!PvBDto6Hs4WbVuu7!efnnGUGob28wvg7EItHJSV1crsjHcx6eUUB7Tj84uTdExGvhIl9lcemPsL5rx4hl3tw3DeUY$"><span style="font-size:12.0pt">http://www.etsi.org</span></a><span style="font-size:12.0pt">.</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- DVB-S2: ETSI EN 302 307 V1.3.1 (2013-03),</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- DVB-S2, Part1, DVB-S2: ETSI EN 302 307-1 V1.4.1 (2014-11), and
</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- DVB-S2, Part2, DVB-S2 Extensions: ETSI EN 302 307-2 V1.2.1 (2020-08).
</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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.
<b><span style="color:red">>>> 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.</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> Please consider the SCCC reply above for 401.0-B.
</span></b><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">C. VCM Protocol (CCSDS 431.1-B-1, February 2021)</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Figure 2-1 of the VCM Protocol Blue Book is:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><img border="0" width="583" height="435" style="width:6.0729in;height:4.5312in" id="_x0000_i1025" src="cid:image003.gif@01D7368F.B3BD7480"><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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. <b><span style="color:red">>>> C&S WG may consider using a uniform term. Andrea & Ken may consider thois point of
discussion.</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Regarding the VCM Protocol itself, the blue book specifies three sets of “modes”:</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- 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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- 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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">- 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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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?
<b><span style="color:red">>>> 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..</span></b></span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt;color:red">>>> 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.</span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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> <span style="color:red">>>> 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 .</span></b></span><o:p></o:p></p>
<p style="margin:0in"><b><span style="font-size:12.0pt"> </span></b><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">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.
<b><span style="color:red">>>> Please consider the SCCC reply above for 401.0-B. </span>
</b> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">Best regards,</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt">John</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:12.0pt"> </span><span style="font-size:10.0pt;font-family:"Courier New"">_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org</span><u><span style="font-size:12.0pt;color:blue"><br>
</span></u><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa__;!!PvBDto6Hs4WbVuu7!efnnGUGob28wvg7EItHJSV1crsjHcx6eUUB7Tj84uTdExGvhIl9lcemPsL5rx4hl3jFKy3BZ$"><span style="font-size:10.0pt;font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</span></a><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).[attachment "CCSDS 431 DVB SCCC pilot approaches.pdf" deleted by Gian
Paolo Calzolari/esoc/ESA] </span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span><o:p></o:p></p>
<p style="margin:0in"><span style="font-size:10.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).</span><o:p></o:p></p>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).<o:p></o:p></pre>
</div>
</body>
</html>