<span style=" font-size:9pt;color:#800080;font-family:sans-serif">-----
Forwarded by Gian Paolo Calzolari/esoc/ESA on 05-03-21 09:27 -----</span>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">sls-bounces@mailman.ccsds.org</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">sls-owner@mailman.ccsds.org</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">04-03-21
23:31</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Auto-discard
notification</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SLS"
<mailman-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<br><tt><span style=" font-size:10pt">The attached message has been automatically
discarded.</span></tt><span style=" font-size:10pt;color:#800080;font-family:sans-serif"><br>
----- Message from "Shames, Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov>
on Thu, 4 Mar 2021 22:30:22 +0000 -----</span>
<table width=785 style="border-collapse:collapse;">
<tr height=8>
<td width=55 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;">
<div align=right><span style=" font-size:12pt"><b>To:</b></span></div>
<td width=726 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;"><span style=" font-size:12pt">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></span>
<tr height=8>
<td width=55 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;">
<div align=right><span style=" font-size:12pt"><b>cc:</b></span></div>
<td width=726 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;"><span style=" font-size:12pt">SEA-SA
<sea-sa@mailman.ccsds.org>, SLS - Space Link Services Area <sls@mailman.ccsds.org></span>
<tr height=8>
<td width=55 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;">
<div align=right><span style=" font-size:12pt"><b>Subject:</b></span></div>
<td width=726 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:1px 1px;"><span style=" font-size:12pt">Re:
[EXTERNAL] It is a smaller sandwich: [Sea-sa] Background materials for
today's SEA-SA SCCS-ARD discussion</span></table>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Hi
Gippo,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks
for the allusion to Scheherazade. Perhaps you also want to reference
the “Dance of the Seven Veils (layers)”? </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Like
you, I wish to keep this discussion in the context of the CCSDS standards
and ISO BRM layer definitions that we always reference. In fact, I want
to constrain this to the realm of “normal” CCSDS standards, those that
obey the “one layer, one protocol, one standard” approach and those that
do not. I brought up “managed parameters” vs “signaled
parameters” because so much of what we do has been “managed”, therefore
not signaled. We can argue why this was the case in the early days
and why it is maybe not the best path as we move into the future. There
are always different options along that spectrum, but that is also something
of a diversion.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">What
I do want to specifically return to is the question I asked of you and
that is feedback on the more detailed diagrams that show the features of
these two multi-layer standards, SCCC and DVB, as compared to the more
normal layer by layer standards. It is a complex topic and worthy
of a better description. I am thinking that we need something like
these diagrams when we revise the SCCS-ADD Green Book, but they will be
useful now as we sort out the best way to address the requirements in the
SCCS-ARD.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">That
said, please do take the time to chew on the draft materials we provided
and provide feedback.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks,
Peter</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Thursday, March 4, 2021 at 1:43 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>SEA-SA <sea-sa@mailman.ccsds.org>, SLS - Space Link Services
Area <sls@mailman.ccsds.org><b><br>
Subject: </b>Re: [EXTERNAL] It is a smaller sandwich: [Sea-sa] Background
materials for today's SEA-SA SCCS-ARD discussion</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Dear
Peter,</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
a friend of mine uses to say that "if
you ask for advice to a sufficient number of persons, at least one will
eventually recommend you what you wanted to do".</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
In the same way, I am sure that looking around for sufficient time we will
find the "One Thousand and One Arabian Layers" book by Shahrazad.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
I think we shall ensure consistency in CCSDS and therefore I stick to CCSDS
books.</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
BTW, I do not find fully correct stating that <in CCSDS we have “data
link” == SDLP and C&S, and “physical” == RF & Mod and now optical>.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
As the figures (in my original mail) show the OSI Data Link Layer is indeed
split by CCSDS into two sublayer. Conversely the Physical Layer (1:1 correspondence
between OSI and CCSDS) can be characterised in many ways: RF, Optical,
Cable, etc.</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
In one case we have splitting, in the other one we have "characterization
(according to physical characteristics)".</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Can you please define what you call <</span><span style=" font-size:11pt;font-family:Calibri">
“normal” CCSDS standards</span><span style=" font-size:10pt;font-family:Arial">>?</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
It is true that in many CCSDS Standards (as e.g. the Space Data Link Protocols,
but not only), in order to conserve bandwidth on the space link, some parameters
associated with the given standard are handled by management rather than
by inline communications protocol. <br>
Usually there is a mixing of managed and inline parameters. Just to mention
an example, </span><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/732x0b3e1.pdf__;!!PvBDto6Hs4WbVuu7!a1HwBJfmgPqbyLxM5N_7XkoL8iISbRk_Y1Hy0vj3mWgXe8oltqVxMjrU7SbXf1GeZ4QN589c$"><span style=" font-size:10pt;color:blue;font-family:Arial"><u>https://public.ccsds.org/Pubs/732x0b3e1.pdf</u></span></a><span style=" font-size:10pt;font-family:Arial">
uses in the Frame Header a Virtual Channel identifier and even a "Signaling
Field".</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
Actually, USLP ( </span><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/732x1b1.pdf__;!!PvBDto6Hs4WbVuu7!a1HwBJfmgPqbyLxM5N_7XkoL8iISbRk_Y1Hy0vj3mWgXe8oltqVxMjrU7SbXf1GeZ2SCt_Be$"><span style=" font-size:10pt;color:blue;font-family:Arial"><u>https://public.ccsds.org/Pubs/732x1b1.pdf</u></span></a><span style=" font-size:10pt;font-family:Arial">
) goes further and - as you know - Greg proudly remarks that USLP increases
the number of signalling fields.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Indeed the </span><span style=" font-size:11pt;font-family:Calibri"> diagrams
I sent do not really reflect any of the details added by the "VCM
family" because it was not the scope of those figures. <br>
Other diagrams in the various standards clarify the details that have nothing
to do with layering. <br>
<br>
My conclusion is that all CCSDS Standards are "normal" CCSDS
Standards and include both managed parameters and inline parameters. <br>
Increasing the inline parameters - as USLP shows just to give an example
outside coding and modulation fields - increases complexity but I am not
aware of a CCSDS mandate for only keeping simple things and/or stopping
progress. <br>
The increased complexity (in general) is a price to pay for modernity and
efficiency and - luckily - a price we can pay thanks to new technologies
as e.g. LDPC codes - invented by Gallager ( </span><a href="https://urldefense.us/v3/__https:/en.wikipedia.org/wiki/Robert_G._Gallager__;!!PvBDto6Hs4WbVuu7!a1HwBJfmgPqbyLxM5N_7XkoL8iISbRk_Y1Hy0vj3mWgXe8oltqVxMjrU7SbXf1GeZzvnCU12$"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>https://en.wikipedia.org/wiki/Robert_G._Gallager</u></span></a><span style=" font-size:11pt;font-family:Calibri">
) in 1960 when their implementation was unrealistic for the technology
available at that time - do show. <br>
<br>
This closes my discussions on layering. <br>
Otherwise I confirm my statement: </span><span style=" font-size:10pt;font-family:Arial">I
still need to digest all the aspects of your message, however I can ensure
that SLS (with proper coordination) will try to provide some punctual technical
comments on the individual items.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
<br>
Best regards <br>
<br>
Gippo <br>
<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">"Shames,
Peter M (US 312B)" <peter.m.shames@jpl.nasa.gov></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Cc: </span><span style=" font-size:9pt;font-family:Arial">"SEA-SA"
<sea-sa@mailman.ccsds.org>, "SLS - Space Link Services Area"
<sls@mailman.ccsds.org></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">03-03-21
23:08</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">Re:
[EXTERNAL] It is a smaller sandwich: [Sea-sa] Background materials for
today's SEA-SA SCCS-ARD discussion</span><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Hi
Gippo,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">We
welcome the inputs from the SLS Area in ensuring that what gets reflected
in the SCCS-ARD is accurate. We use as sources for all of these materials
the published standards (and the draft ones that are sufficiently mature,
as noted).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">As
for “how many layers”, that sort of depends on how you count them. We
all know that the ISO BRM only lists “data link - layer 2” and “physical
- layer 1”. But in CCSDS we have “data link” == SDLP and C&S,
and “physical” == RF & Mod and now optical. The fact that
C&S and RF&Mod both include an “and” reflects that these are
themselves compound entities, with “sub-layers” of sorts. And we
are all aware that SDLP frame lengths get bound to C&S block lengths
in special ways.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Furthermore,
in all of the “normal” CCSDS standards the approach that has consistently
been taken is to use “managed parameters” in many cases and thereby require
that the two ends of the comm link, sender and receiver, coordinate ahead
of time and choreograph communications assets for pointing as well as choreograph
data rate changes and changes to “communications modes”, such as low
rate, high rate, emergency mode, one-way, two-way, etc. It all gets
pre-planned and “baked in” to the communications pass. There is
no signaling aside from whatever gets transmitted.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">But
in the SCCC and DVB-S2, and now the VCM too, we introduce a new signaling
mechanism, a new physical layer “framing” approach, and with ACM a feedback
loop from receiver back to sender. The diagrams you sent do not really
reflect any of this added detail or complexity, which is why we produced
the more detailed diagrams that show these features, which were extracted
from the standards themselves. It would be useful to have your team
review these more accurate diagrams and make sure that they correctly reflect
the all of the features, and their ordering and connections, that are present
in these standards. I find them to be much more useful than those
block diagrams that leave out all of these details.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Is
that something you can do?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">We
can argue over how many “layers”, relative to the ISO BRM, but it seems
pretty clear that CCSDS has for years been treating L1 and L2 as having
sub-layers. And it seems pretty clear that these newer, more complicated,
standards introduce even more sub-layers, as well as some new “cross layer”
management and control “sub-layers” that live “on the side” and control
behavior of these other sub-layers.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">It
would be good to get your feedback to make sure that we represent all of
this accurately.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">Thanks,
Peter</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"><b>From:
</b>Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Wednesday, March 3, 2021 at 10:18 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>SEA-SA <sea-sa@mailman.ccsds.org>, SLS - Space Link Services
Area <sls@mailman.ccsds.org><b><br>
Subject: </b>[EXTERNAL] It is a smaller sandwich: [Sea-sa] Background materials
for today's SEA-SA SCCS-ARD discussion</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Dear
Peter,</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:Arial"><br>
I must say that I am quite puzzled by this mail.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
I still need to digest all the aspects of your message, however I can ensure
that SLS (with proper coordination) will try to provide some punctual technical
comments on the individual items.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Here, after a check with SLS colleagues, I want to comment on your statement
about the </span><span style=" font-size:12pt">“3-layer sandwich” </span><span style=" font-size:10pt;font-family:Arial">.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Indeed that sandwich is not so big as you claim.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Actually all the following documents</span><span style=" font-size:12pt">
</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/131x2b1e1.pdf__;!!PvBDto6Hs4WbVuu7!demyENKGsE_7PJJrR6SbeOXkhtjiGFopt8LGoDr7ESP8cpphnhgTNO8cfJxgRGhPQApStP0N$"><span style=" font-size:10pt;color:blue;font-family:Arial"><u>https://public.ccsds.org/Pubs/131x2b1e1.pdf</u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/131x3b1.pdf__;!!PvBDto6Hs4WbVuu7!demyENKGsE_7PJJrR6SbeOXkhtjiGFopt8LGoDr7ESP8cpphnhgTNO8cfJxgRGhPQHLhWGkA$"><span style=" font-size:10pt;color:blue;font-family:Arial"><u>https://public.ccsds.org/Pubs/131x3b1.pdf</u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/public.ccsds.org/Pubs/431x0b1.pdf__;!!PvBDto6Hs4WbVuu7!demyENKGsE_7PJJrR6SbeOXkhtjiGFopt8LGoDr7ESP8cpphnhgTNO8cfJxgRGhPQEFDXIjo$"><span style=" font-size:10pt;color:blue;font-family:Arial"><u>https://public.ccsds.org/Pubs/431x0b1.pdf</u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
clearly state that "This Recommended Standard covers the functions
of both the Synchronization and Channel Coding Sublayer and the Physical
Layer"; i.e. the layers combined are two (or let's say 1 and half
as one layer and one sublayer are combined).</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
They all also show this (even with some minor differences) in their "Figure
2-1: Relationship with OSI Layers" showing together the</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
1) Synchronization and Channel Coding Sublayer that provides methods of
synchronization and channel coding for transferring Transfer Frames over
a space link and the <br>
2) Physical Layer that provides the RF and modulation methods for transferring
a stream of bits over a space link in a single direction</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
For reference the three figures are attached as snapshots.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Best regards</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Gian Paolo </span><span style=" font-size:12pt"><br>
<br>
<br>
</span><img src=cid:_1_0D0757400D074278002E7C6AC125868F style="border:0px solid;"><img src=cid:_1_0D0759740D074278002E7C6AC125868F style="border:0px solid;"><img src=cid:_1_0D075BA80D074278002E7C6AC125868F style="border:0px solid;"><span style=" font-size:12pt">
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
<br>
From: </span><span style=" font-size:9pt;font-family:Arial">"Shames,
Peter M\(US 312B\) via SEA-SA" <sea-sa@mailman.ccsds.org></span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"SEA-SA"
<sea-sa@mailman.ccsds.org></span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">02-03-21
23:37</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">[Sea-sa]
Background materials for today's SEA-SA SCCS-ARD discussion</span><span style=" font-size:12pt">
</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"
<sea-sa-bounces@mailman.ccsds.org></span><span style=" font-size:12pt">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial"><br>
<br>
[attachment "431x1b0_CESG_Approval.pdf" deleted by Gian Paolo
Calzolari/esoc/ESA] </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri"><br>
Dear SCCS-ARD sub-team,</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
During today’s SEA-SA SCCS-ARD discussion we spent quite a period of time
discussing the challenges in create a reasonably compact, and also accurate,
table that reflects the currently documented set of configurations that
are made available by the suite of space data link, coding, synchronization,
modulation, RF (and optical), and physical layer signaling standards. There
are many situations where there is no one, simple, statement, or even set
of statements, that can be made. We have had to resort to a tabular
presentation, Table 6-8 in Sec 6 on protocols, to address this.
A copy of this table is attached, along with the “cheat sheet” of notes
that encode the cells in this table.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
Any standards that are expected to come into being within the next 6-12
months, but that are not yet final, are highlighted in yellow. We
hope these are final before we publish this document, but all of those
dates are still rather uncertain.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
Note that uplink is separate from downlink, that RF coding and modulation
is separate from optical coding and modulation, and that SCCC and DVB-S2
(which both contain coding, modulation, and physical layer signaling in
a single standard) are separated from the “normal” CCSDS standards that
break these into three separate layers. The new Variable Coding and
Modulation (VCM) spec that is now in progress is also shown as a separate
layer. This VCM spec is related to the “bottom” parts of the DVB
and SCCC specs, but it is different from them in distinct ways. </span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
It became clear during discussion that most of those on the call were unfamiliar
with the details and complexities represented in this table. Furthermore,
most are unfamiliar with the complexities inherent in the “3-layer sandwich”
that SCCC and DVB present, and with how they compare with the “normal”
CCSDS link layer, coding, synch, modulation, physical layer and RF stack.
I have attached a presentation that some of us constructed in order
to make sure that we understood what those relationships are. It
is named “SEA high rate comm issue 1Mar21” and is attached here. This
is a statement of the recent issues and also a set of diagrams comparing
these different protocol sets. It does not address optical comm.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
It should be noted that the “bottom” part of the DVB and SCCC specs includes
a specialized set of physical layer signaling mechanisms. These
are not present in normal CCSDS protocol stacks, where any choices that
are made for different coding, synchronization, and modulation combinations
are made “by management”. That phrase “by management” means that
the mission manages these choices manually, outside of the protocols themselves,
that the protocol layers contain no “signals” as to which choices were
made, and that any changes to the coding and modulation must be agreed
to and managed out of band, by pre-agreement. </span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
In the DVB and SCCC, and in the new draft CCSDS VCM spec (CCSDS 431.1-b-1)
which is attached here as a CESG draft spec, a physical layer signaling
mechanism is introduced. VCM is defined as “<b>variable coded modulation,
VCM</b>: A method to adapt the transmission scheme to channel conditions
following a predetermined schedule. ”. This includes two separate
physical layer structures: 1) the “Pilot Symbols” and 2) the encoded
and modulated data symbols. The CCSDS 431.1 spec describes two different
VCM “types”. Type 1 uses the DVB-S2 VCM pilot symbol and data symbol
length approach, Type 2 uses the SCCC VCM pilot symbol and data symbol
length approach. These pilot symbols are, in both cases, just short
blocks of 7 bits, protected by a linear code and BPSK modulation (see attached
Table from Annex E). Five of these bits are used to identify one
of the 32 possible sets of code and modulation pairs that are applied to
the encoded and modulated symbols that follow the pilot. </span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
Where these DVB Type 1, SCCC Type 2, and CCSDS Type 1 or 2 schemes differ
is in the length of the symbol strings and the sets of code/modulation
pairs that are allowed. </span><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<ul>
<li><span style=" font-size:11pt;font-family:Calibri">DVB-S2 has its own
set shown in Table 3-4. It allows different code rates, from 1 /
4 (0.25) up to 9 / 10 (0.9), different input lengths from 2992 up to 58112
bits, different modulations (QPSK, 8-PSK, 16 & 32-APSK) and its own
set of DVB-S2 codes that are patented. </span>
<li><span style=" font-size:11pt;font-family:Calibri">SCCC has its own
set shown in Table 3-3. It allows different code rates, from 0.36
up to 0.9, different input lengths from 5758 up to 43678 bits, the same
set of modulations (QPSK, 8-PSK, 16 & 32-APSK) and its own set of SCCC
codes that are patented. </span>
<li><span style=" font-size:11pt;font-family:Calibri">The CCSDS VCM has
its own set shown in Table 3-2. It allows different (CCSDS standard)
code rates, from 1 / 6 (0.16) up to 223/255 (0.875), different (CCSDS standard)
input lengths from 1748 up to 16384 bits, the same set of modulations plus
BPSK (BPSK, QPSK, 8-PSK, 16 & 32-APSK) and the standard LDPC codes.
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span></ul><span style=" font-size:11pt;font-family:Calibri">You can see
that these are similar, and that the modulation set largely overlaps, but
they are different. In all cases specialized equipment will be needed
in the RF front ends to handle the pilot symbols and the continually changing
coding and modulation . The other difference is that the CCSDS VCM
expects to signal a pre-planned set of code & modulation changes, but
the SCCC and DVB-S2 also include adaptive coding and modulation (ACM),
which uses signals sent back from the receiver to the sender. To
quote from SCCC, CCSDS 131x2b1d1, Sec 3.2.7: </span><span style=" font-size:12pt;color:#424282;font-family:TimesNewRomanPSMT"><br>
NOTE – <br>
Changes of the value of the information block size </span><span style=" font-size:12pt;color:#424282;font-family:Calibri"><i>K
</i></span><span style=" font-size:12pt;color:#424282;font-family:TimesNewRomanPSMT">are
done by a system to adjust the modulation and coding schemes. This is achieved
through, e.g., one of the following approaches: the ground receiver provides
the signal quality estimation (or prediction) through a feedback channel
(e.g., via telecommand) or the change of modulation and coding schemes
is pre-scheduled for each satellite pass based on geometrical information
(elevation angle). </span><span style=" font-size:12pt;font-family:Calibri"><br>
So the SCCC may use a feedback loop, but no specific protocol appears to
be specified for this. The DVB-S2 standard, as adapted for CCSDS,
makes essentially the same statement. The full ETSI DVB-S2 spec,
however, defines an actual feedback protocol that is, in my opinion, only
of use over a near Earth (or at least a “local”) communications path
where the RTLT is sufficiently short to allow requests for data rate
changes to be responded to. This is not appropriate for use in deep
space where the RTLT may be measures in 10’s of minutes or tens of hours.
They also bring substantial added complexity which, in the general
case, may not be worth the added cost of engineering, testing, etc unless
the mission is a) in a near Earth orbit, and b) can make use of available
commercial parts.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
As I suggested during the webex, I think we must treat the following groups
of standards separately, because to do otherwise will overly complicate
the core of the CCSDS standard suite, that I estimate meets 95% of the
users.</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
1. </span><span style=" font-size:12pt;font-family:Calibri">The
“CCSDS standard” suite of link layer, coding, synchronization, modulation,
and RF standards</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
2. </span><span style=" font-size:12pt;font-family:Calibri">A
subsection on the Optical coding and modulation standards that slot in
underneath the normal link layer protocols, along with a brief description</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
3. </span><span style=" font-size:12pt;font-family:Calibri">A
separate subsection on the VCM and the associated SCCC and DVB-S2 “omnibus”
standards that replace the standard CCSDS coding, synchronization, modulation
and add physical layer signaling.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
If anyone has issues with this approach please bring them up now. I
think this is the only sensible way to handle this issue of these very
different approaches to the lower layer protocols.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
Thanks, Peter</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org</span><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa__;!!PvBDto6Hs4WbVuu7!demyENKGsE_7PJJrR6SbeOXkhtjiGFopt8LGoDr7ESP8cpphnhgTNO8cfJxgRGhPQGEAEmdJ$"><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><span style=" font-size:11pt;font-family:Calibri">
</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial"><br>
[attachment "SEA High Rate comm issue 1Mar21.pptx" deleted by
Gian Paolo Calzolari/esoc/ESA] [attachment "CCSDS 431 VCM protocol
layers.pdf" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment
"CCSDS 431 VCM pilot pattern.pdf" deleted by Gian Paolo Calzolari/esoc/ESA]
[attachment "CCSDS 431 DVB SCCC pilot approaches.pdf" deleted
by Gian Paolo Calzolari/esoc/ESA] [attachment "SCCS-ARD Table 6-8
Notes 1Mar21.pdf" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment
"SCCS-ARD Table 6-8 proto layer options.pdf" deleted by Gian
Paolo Calzolari/esoc/ESA] </span></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 (dpo@esa.int).</span></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 (dpo@esa.int).</span></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>