<span style=" font-size:10pt;font-family:sans-serif">[attachment "Spaghetti2021.ppt"
deleted by Gian Paolo Calzolari/esoc/ESA] </span>
<br><span style=" font-size:10pt;font-family:sans-serif">Dera Peter,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
here attached SLS comments to slide 9 and 10 of "SEA
High Rate comm issue 1Mar21.pptx"</span>
<br><span style=" font-size:10pt;font-family:sans-serif">We focused on
those two slides because of the diagrams that are addressing books produced
in SLS.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Absence on comments
on other slides or other parts of your mail does not imply SLS agreement.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The two original
slides are attached here below for easier reference.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I tell you that
there was a quite spread opinion about the fact that your slides 9 and
10 contained obsolete material for which was not worth commenting in detail
before an update.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Nevertheless some
focused comments were gathered and they are reported below.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">-----------------------------------------------------------------------------</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><b>SLIDE 9 - Current
CCSDS Layered Protocol Stack, with CNES & ESA “add-ons” shown</b></span>
<br><span style=" font-size:10pt;font-family:sans-serif">1) The box Encapsulation
service shall be renamed Encapsulation Packet protocol </span>
<br><span style=" font-size:10pt;font-family:sans-serif">2) the box for
Encapsulation is linked to 4 out of the 5 SDLP boxes immediately below
(while SPP is connected to all fives boxes). Link to TC SDLP is missing
and shall be added. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">3) Diagram can
be simplified replacing the two boxes for SPP and EPP with a single box
(connected to the 5 SDLP boxes immediately below) named e.g. SPP/EPP (even
in longer form) </span>
<br><span style=" font-size:10pt;font-family:sans-serif">4) The DVB+SCCC
separate box is only connected to TM Space Data Link Protocol. This is
wrong. Possibility of transmitting AOS Frames is there since the beginning
while addition of USLP Frames is in progress. However this is in progress
also for 131.0 and the consequence is that the present diagram shows
an unbalanced preference for TM Coding..Of course one could remove the
USLP link to TM Coding book, but it may be better to simplify the diagram
showing that TM/OAS/AOS SDLP's are equally connected to TM Coding, SCCC,
and DVB-S2 books. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">5) SLS strongly
disagree with the statement: "Issue: These CNES and ESA, agency unique,
“omnibus standards” are not aligned with the rest of CCSDS, but are glued
on the side." Those two standards provides the same type of service
provided by 131.0-B but the WGs agreed to assign them separate books for
their peculiarities without detracting from the other book. At the extreme,
one could state that also the separate book for Proximity-1 is an issue
as it is separate from TC Coding. Idem for Proximity-1 physical layer.
To be removed. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">6) The statement
"They combine several layers into one spec, act as separate, parallel,
coding, modulation, and signaling layers to the “mainline” CCSDS."
is at least inaccurate and it is perceived to have the purpose to
give a negative accent to those two standards and to the works of the WG/Area.To
be removed. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">7) The statement
"Span Data Link, Coding and Sync, Slicing, Modulation, and Physical
Layer signaling" is inaccurate and not precise. It mixes layers (or
sublayers) with procedures within layers (e.g. slicing, modulation, etc.).
Putting together < Data Link, Coding> is highly ambiguous as it could
be understood as either "the Synchronization and Channel Coding Sublayer
of the Data Link layer" or "the complete Data Link Layer including
both the Data Link Protocol Sublayer and the Synchronization and Channel
Coding Sublayer". It can be guessed that the original intention was
the latter and this is clearly wrong because no one of the three 131.x
standards affects the Data Link Protocol Sublayer. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">8) The statement/bullets
<These “integrated suites” duplicate Coding & Data Link Layer
functions: * variable-to-fixed length conversion * idle data insertion>
is wrong. There is no variable-to-fixed length conversion performed by
the 131.x standards since even the slicing is applied to fixed length
frames in input. There is no idle data insertion performed by the
131.x standards (note that the word idle is not present in </span><a href=https://public.ccsds.org/Pubs/131x2b1e1.pdf><span style=" font-size:10pt;font-family:sans-serif">https://public.ccsds.org/Pubs/131x2b1e1.pdf</span></a><span style=" font-size:10pt;font-family:sans-serif">
while in </span><a href=https://public.ccsds.org/Pubs/131x3b1.pdf><span style=" font-size:10pt;font-family:sans-serif">https://public.ccsds.org/Pubs/131x3b1.pdf</span></a><span style=" font-size:10pt;font-family:sans-serif">
it is used only to explain the unused acronym OID). </span>
<br><span style=" font-size:10pt;font-family:sans-serif">9) The layers
label on the left are wrong. The label "Data Link Layer"
shall be replaced by " Data Link Protocol Sublayer". The "Coding
and Modulation Sublayer" does not exist and that label shall be replaced
by " Synchronization and Channel Coding Sublayer". </span>
<br><span style=" font-size:10pt;font-family:sans-serif">10) The height
of the DVB and SCCC boxes is wrong when "linked" to the labels
on the left for the layers. This is another case where the drawing seems
to be done to purposely give a negative accent to those two standards:
while they match the ordering of the boxes on the right they do not match
the SCCC and DVB boxes. First of all SCCC and DVB-S2 shall have the
same height as they covers the same layers. Second they height shall be
such that only "Synchronization and Channel Coding Sublayer"
and "Physical Layer" </span>
<br><span style=" font-size:10pt;font-family:sans-serif">11) the labels
for books at the centre of the slide are not all necessary. In the diagram
there is no silver book, there are no pink sheets, there is no white paper.
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">12) To be picky,
the box for 231.0 should extend a little towards the physical layer
because of the PLOP(s). See also Figure 2-1: Relationship with OSI Layers
in </span><a href=https://public.ccsds.org/Pubs/231x0b3.pdf><span style=" font-size:10pt;color:blue;font-family:sans-serif">https://public.ccsds.org/Pubs/231x0b3.pdf</span></a><span style=" font-size:10pt;font-family:sans-serif">
</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">------------------------------------------------------------------</span>
<br><span style=" font-size:10pt;font-family:sans-serif"><b>SLIDE 10 -
Detail of SCCC and DVB-S2 “integrated Data Link and Physical Layers</b></span>
<br><span style=" font-size:10pt;font-family:sans-serif">1) The box labelled
TM SDLP shall be labelled "TM/AOS/USLP SDLP". knowing that USLP
is coming soon for all the three 131.x coding books.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">2) On the left
side of the drawing, the label "Data Link Layer" shall
be replaced by " Data Link Protocol Sublayer"</span>
<br><span style=" font-size:10pt;font-family:sans-serif">3) On the left
side of the drawing, the label "Coding Sublayer of Data Link
Layer" shall be replaced by "Synchronization and Channel Coding
Sublayer" </span>
<br><span style=" font-size:10pt;font-family:sans-serif">4) The SCCC and
DVB-S2 boxes shall have the same height.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">5) The SCCC box
height shall not exceed into the Data Link Protocol Sublayer</span>
<br><span style=" font-size:10pt;font-family:sans-serif">6) The DVB-S2
box height shall not exceed into the Data Link Protocol Sublayer</span>
<br><span style=" font-size:10pt;font-family:sans-serif">7) The Space Data
Link Protocols perform no slicing. The box "Slice" in SDLP box
(upper right corner of the drawing)shall be removed.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">8) The "Fill
frames" box in the SDLP box (upper right corner of the drawing)
shall be renamed "OID Frames"</span>
<br><span style=" font-size:10pt;font-family:sans-serif">9) I understand
that the SDLP box (upper right corner of the drawing) tries to give
a summary of that processing, but I wonder whether the actual boxes (after
corrections) show something reasonable. I send separately my proposal to
<b>Greg and Matt</b>.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">10) in the TM
S&CC box, the box names LDPC should be renamed (e.g. "LDPC +/-
slic."?) or there should be two LDPC boxes to show the possibility
of slicing.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">11) in the TM
S&CC box, it could be good adding something showing the concatenated
codes.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">12) In the RF
& Mod Box, showing only "Modulation: BPSK, QPSK" looks a
limitation. It could be wise to rename it at least "Modulation: BPSK,
QPSK, etc."</span>
<br><span style=" font-size:10pt;font-family:sans-serif">13) In the RF
& Mod Box, does the "Filter" box make sense?</span>
<br><span style=" font-size:10pt;font-family:sans-serif">14) As for the
comment on the previous slide.... The statement "Span Data Link, Coding
and Sync, Slicing, Modulation, and Physical Layer signaling" is inaccurate
and not precise. It mixes layers (or sublayers) with procedures within
layers (e.g. slicing, modulation, etc.). Putting together < Data Link,
Coding> is highly ambiguous as it could be understood as either "the
Synchronization and Channel Coding Sublayer of the Data Link layer"
or "the complete Data Link Layer including both the Data Link Protocol
Sublayer and the Synchronization and Channel Coding Sublayer".I guess
the original intention was the latter and this is clearly wrong because
no one of the three 131.x standards affects the Data Link Protocol Sublayer.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">15) The statement
"Parallel to “main-line” CCSDS standards from data link down"
it is not clear.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">16) SLS
strongly disagree with the stated issue "</span><span style=" font-size:10pt;color:red;font-family:sans-serif">These
agency unique, down-link only, approaches are not truly interoperable
with each other nor with the rest of CCSDS</span><span style=" font-size:10pt;font-family:sans-serif">".
What does it mean "</span><span style=" font-size:10pt;color:red;font-family:sans-serif">
interoperable with each other </span><span style=" font-size:10pt;font-family:sans-serif">"?
Are e.g. Turbo Codes interoperable with LDPC Codes? Are LDPC codes
interoperable with Concatenated Codes? Is anything preventing a system
implementing either SCCC or DVB-S2 decoding from providing SLE RAF? Is
anything preventing a system implementing either SCCC or DVB-S2 decoding
from providing SLE RCF? Actually one company integrating SCCC in an existing
equipment plans to rpovide RAF/RCF independtly from the used ddecoder.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">17) The added
comment "</span><span style=" font-size:10pt;color:red;font-family:sans-serif">And
they are now being proposed as suitable for downlink, uplink, and cross-link
for all deployments, including Lunar and deep space</span><span style=" font-size:10pt;font-family:sans-serif">"
is irrelevant and forgets that such a proposal has been accepted by the
WG and even by CMC that approved the relevant projects.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">18) rightmost
column (conventional VCM/RFM), modulation is not only BPSK and QPSK but
all HOMs up to 64-APSK (recommendations 2.4.18 and 2.4.23). The only difference
modulation-wise is that SCCC/DVB-S2 do not have BPSK since intended for
high data rate use.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">19) There is only
one method for interfacing DVB-S2 specified in CCSDS DVB-S2 recommendation
(131.3-B). This method is called Generic Stream (GS) mode. It is fully
DVB-S2 compatible. So it is not understood what is method 1 (DVB) and method
2 (non DVB) depicted in this block diagram. There is only one method :
Generic Stream (GS) mode – one of the standard input mode for DVB-S2.
The number of BCH code options is debatable: 2 not 4 : short
and normal (FECFRAME). There number of LDPC code options is debatable (11
and not 28). Moreover, it is not understood why SEA document/discussion
needs a so big level of detail (number of code options for Turbo, Reed-Solomon,
Convolutional, LDPC codes is not mentioned in the same diagram). In general,
details should be in the document defining them. Spreading them in other
books only increases the risk of future inconsistencies and a domino effect
for updates whenever the source document changes.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">------------------------------------------------------------------------</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">In parallel Ken
Andrews, author of the original drawings from which your two slides were
extrapolated, volunteered to produce updated diagrams implementing most
of the technical comments above.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">To save time,
I am sending you the latest version (*) produced by Ken (and for which
I am very grateful) that I find to be a great improvement with respect
to what originally in your slides.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Please be aware
that not all the persons involved in this discussion commented them in
detail (there were a few comments after a first update by Ken) and for
this reason I cannot assure this version is fully conclusive (i.e there
could be additional comments)..</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I hope I succeeded
in reporting correctly and honestly the interaction with the other SLS
Players.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Best regrads</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">(*) As Ken distributed
two versions with the same name, I renamed the latest one to show the full
date. The contents are untouched.<br>
<br>
</span>
<br>
<br>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Shames,
Peter M\(US 312B\) via SEA-SA" <sea-sa@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">"SEA-SA"
<sea-sa@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">02-03-21
23:37</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[Sea-sa]
Background materials for today's SEA-SA SCCS-ARD discussion</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">"SEA-SA"
<sea-sa-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">[attachment "431x1b0_CESG_Approval.pdf"
deleted by Gian Paolo Calzolari/esoc/ESA] </span>
<br>
<p style=";■xÊ䀰N■N■ttachment "431x1b0_CESG_Approval.pdf"
deleted by Gian Paolo Calzolari/esoc/ESA] full
date. The contents are untou┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">Dear
SCCS-ARD sub-team,</span></p>
<p style=";■xÊ됞N■N■ar
SCCS-ARD sub-team,0_CESG_Approval.pdf"
deleted by Gian Paolo Calzolari/esoc/ESA] full
date. The contents are untou┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ簣N■N■bsp;SCCS-ARD sub-team,0_CESG_Approval.pdf"
deleted by Gian Paolo Calzolari/esoc/ESA] full
date. The contents are untou┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊN■N■d to resort to a tabular
presentation, Table 6-8 in Sec 6 on protocols, to address this.
A copy of this table is atta┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ렸N杓N■bsp; resort to a tabular
presentation, Table 6-8 in Sec 6 on protocols, to address this.
A copy of this table is atta┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊ框N■N■n yellow. We hope these
are final before we publish this document, but all of those dates are still
rather uncertain.a┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊN■N■bsp;llow. We hope these
are final before we publish this document, but all of those dates are still
rather uncertain.a┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊᡌN施N■the DVB and SCCC specs,
but it is different from them in distinct ways. parate from optical coding and modulation, and that SCCC and DVB-S2 (which
both co</span>"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊN■N■bsp;DVB and SCCC specs,
but it is different from them in distinct ways. parate from optical coding and modulation, and that SCCC and DVB-S2 (which
both co</span>"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊ屓N癚N■lationships are. It
is named “SEA high rate comm issue 1Mar21” and is attached here. This
is a statement of th┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊᑃN■N■bsp;onships are. It
is named “SEA high rate comm issue 1Mar21” and is attached here. This
is a statement of th┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊ䁛N偛N■o 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. ese
are not pre</span>"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ聉N孃N■bsp;ich choices were
made, and that any changes to the coding and modulation must be agreed
to and managed out of band, by pre-agreement. ese
are not pre</span>"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊN■N■ust 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
</span>"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ쑐N■N■bsp;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
</span>"><span style=" font-size:11pt;font-family:Calibri">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></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>
<p style=";■xÊだ■Ä]■4he 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 m><span style=" font-size:11pt;font-family:Calibri"> </span></p></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>
<p style=";■xÊ屨■ðe■ to the sender. To
quote from SCCC, CCSDS 131x2b1d1, Sec 3.2.7:ly overlaps,
but they are different. In all cases s┘}
■îî"><span style=" font-size:12pt;color:#424282;font-family:TimesNewRomanPSMT">NOTE
– </span></p>
<p style=";■xÊ灡■j■.OTE
– ender. To
quote from SCCC, CCSDS 131x2b1d1, Sec 3.2.7:ly overlaps,
but they are different. In all cases s┘}
■îî"><span style=" font-size:12pt;color:#424282;font-family:TimesNewRomanPSMT">Changes
of the value of the information block size </span><span style=" font-size:12pt;color:#424282"><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></p>
<p style=";■xÊၰ■m■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
t</span>"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊ㱴■Ðq■N deep space
where the RTLT may be measures in 10’s of minutes or tens of hours. They
also bring substantial added comp┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ■Dw■nbsp; space
where the RTLT may be measures in 10’s of minutes or tens of hours. They
also bring substantial added comp┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊ桼■üy■!s
I suggested during the webex, I think we must treat the following groups
of standards separately, because to do otherwise w┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ顝■0}■nbsp;suggested during the webex, I think we must treat the following groups
of standards separately, because to do otherwise w┘}
■îî"><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">The
“CCSDS standard” suite of link layer, coding, synchronization, modulation,
and RF standards</span></p>
<p style=";■xÊ⒄■è■4he
“CCSDS standard” suite of link layer, coding, synchronization, modulation,
and RF standardsly, because to do otherwise w┘}
■îî"><span style=" font-size:10pt;font-family:sans-serif">2.
</span><span style=" font-size:11pt;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></p>
<p style=";■xÊ傇■¸ä■!
subsection on the Optical coding and modulation standards that slot in
underneath the normal link layer protocols, along wit┘}
■îîê■Ption
the core of t</span>"><span style=" font-size:10pt;font-family:sans-serif">3.
</span><span style=" font-size:11pt;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></p>
<p style=";■xÊ낊■ê■!
separate subsection on the VCM and the associated SCCC and DVB-S2 “omnibus”
standards that replace the standard CCSDS codi┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ貄■¤ï■nbsp;arate subsection on the VCM and the associated SCCC and DVB-S2 “omnibus”
standards that replace the standard CCSDS codi┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">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></p>
<p style=";■xÊꢐ■ Ä■)f
anyone has issues with this approach please bring them up now. I
think this is the only sensible way to handle this i┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ碋■Læ■nbsp;yone has issues with this approach please bring them up now. I
think this is the only sensible way to handle this i┘}
■îî"><span style=" font-size:11pt;font-family:Calibri">Thanks,
Peter</span></p>
<p style=";■xÊႎ■￤ö■4hanks,
Peter issues with this approach please bring them up now. I
think this is the only sensible way to handle this i┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ■û■nbsp;,
Peter issues with this approach please bring them up now. I
think this is the only sensible way to handle this i┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style=";■xÊ■Ö■nbsp;,
Peter issues with this approach please bring them up now. I
think this is the only sensible way to handle this i┘}
■îî"><span style=" font-size:11pt;font-family:Calibri"> </span><tt><span style=" font-size:10pt">_______________________________________________<br>
SEA-SA mailing list<br>
SEA-SA@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt></p>
<br><span style=" font-size:10pt;font-family:sans-serif">[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>
<br>
<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>