<span style=" font-size:10pt;font-family:sans-serif">Dear Peter,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
please find here attached a few comments on the two
files addressing Table 6-8 and the $B!H(Bcheat sheet$B!I(B of notes that encode
the cells in this table.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">About the "separations"
you mentions, the following is understood (with no comment now):</span>
<br><span style=" font-size:10pt;font-family:sans-serif">A) uplink is separate
from downlink ==> RAF, RCF, and ROCF columns refer to downlink, F-CLUTU
and FF-CSTS columns refer to uplink</span>
<br><span style=" font-size:10pt;font-family:sans-serif">B) RF coding and
modulation is separate from optical coding and modulation ==> only one
row addresses optical comms (coding + physical layers) while two rows are
dedicated to TM Coding 131.0 and RFM 401.0</span>
<br><span style=" font-size:10pt;font-family:sans-serif">C) SCCC and DVB$B!>(BS2
(which both contain coding, modulation, and physical layer signaling in
a single standard) are separated from the $B!H(Bnormal$B!I(B CCSDS standards that
break these into three separate layers ==> two rows are dedicated to
SCCC and DVB-S2 standards</span>
<br><span style=" font-size:10pt;font-family:sans-serif">D) 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 $B!H(Bbottom$B!I(B parts of
the DVB and SCCC specs, but it is different from them in distinct ways.
==> There is a dedicated row fro VCM (though the table seems to miss
an orizontal line after RFM).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">With respect to
VCM (now published) it does not look correct to me to state that it is
related to the $B!H(Bbottom$B!I(B parts of the DVB and SCCC specs.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Actually it should
be considered having an equivalent behaviour to SCCC and DVB-S2.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">However let's
look at the table row by row (more or less).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">1) N4 statement
is incorrect. RAF as specified today does not handle variable length frames.
Even if formally the service provision could handle it, the production
part is specified to support only fixed length frames.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">2) AOS - it looks
that the C2 here means OK unless lower layer is TC Coding. Would the shorter
formulation referring to TC or a remark/note help the reader? Most likely
that meaning is true for all occurrences of C2.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">3) Fixed Length
USLP - What is R3?</span>
<br><span style=" font-size:10pt;font-family:sans-serif">4) TC SDLP - the
box for RAF shall be empty.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">5) Variable Length
USLP - currently not allowed for downlink. RAF cannot support it at the
time being. What is the sense of C3 for RAF and RCF? Does anybody plan
to use TC coding for the downlink of USLP variable length frames? What
is R4?</span>
<br><span style=" font-size:10pt;font-family:sans-serif">6) Why the second
sentence of N5 refers to RAF and not to CLTU?</span>
<br><span style=" font-size:10pt;font-family:sans-serif">7) VCM - Which
O? I think that VCM can also use HOMs and should be treated as SCCC and
DVB-S2</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The reading and
evaluation of this Table is very painful and confusing and most likely
other comments could easily be produced.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">In addition to
this, I would like to better focus some misunderstanding about the handling
of VCM (intended as methods and not as 431.0-B) and ACM.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The receiver does
not change for VCM and ACM and does not depend on the duration of the time
interval in which a ModCod is applied.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">What changes is
how the transmitter decides to apply changes of ModCod. A ModCod may remain
constant for days. weeks, months (e.g. based on seasons, whether forecast,
etc.)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">In case of ACM,
the expectation is for a process external to the receiver that - based
on the SNR estimation etc, something provided by all receivers on the market
- decides how to instruct the transmitter to change ModCod at intervals
of second or (most likely) minutes. This kind of side process (i.e. external
to the VCM/ACM mechanism per-se) in a typical space to ground configuration
may interact with the sending spacecraft e.g sending command with Forward
Frame Service.</span>
<br>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Best regards</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo </span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"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>
<br><span style=" font-size:11pt;font-family:Calibri">Dear SCCS-ARD sub-team,</span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><span style=" font-size:11pt;font-family:Calibri">During today$B!G(Bs 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 $B!H(Bcheat sheet$B!I(B of notes
that encode the cells in this table.</span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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 $B!H(Bnormal$B!I(B 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 $B!H(Bbottom$B!I(B parts of the DVB and SCCC specs,
but it is different from them in distinct ways. </span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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 $B!H(B3-layer sandwich$B!I(B that
SCCC and DVB present, and with how they compare with the $B!H(Bnormal$B!I(B 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
$B!H(BSEA high rate comm issue 1Mar21$B!I(B 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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><span style=" font-size:11pt;font-family:Calibri">It should be noted
that the $B!H(Bbottom$B!I(B 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 $B!H(Bby management$B!I(B.
That phrase $B!H(Bby management$B!I(B means that the mission manages these
choices manually, outside of the protocols themselves, that the protocol
layers contain no $B!H(Bsignals$B!I(B 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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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!H(B<b>variable coded modulation, VCM</b>: A method
to adapt the transmission scheme to channel conditions following a predetermined
schedule. $B!I(B. This includes two separate physical layer structures:
1) the $B!H(BPilot Symbols$B!I(B and 2) the encoded and modulated data symbols.
The CCSDS 431.1 spec describes two different VCM $B!H(Btypes$B!I(B. 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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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>
<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>
<br><span style=" font-size:11pt;font-family:Calibri"> </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>
<br><span style=" font-size:12pt;color:#424282;font-family:TimesNewRomanPSMT">NOTE
$B!>(B </span>
<br><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>
<br><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 $B!H(Blocal$B!I(B) 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$B!G(Bs 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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><span style=" font-size:10pt;font-family:sans-serif">1.
</span><span style=" font-size:11pt;font-family:Calibri">The
$B!H(BCCSDS standard$B!I(B suite of link layer, coding, synchronization, modulation,
and RF standards</span>
<br><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>
<br><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 $B!H(Bomnibus$B!I(B
standards that replace the standard CCSDS coding, synchronization, modulation
and add physical layer signaling.</span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><span style=" font-size:11pt;font-family:Calibri">Thanks, Peter</span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><span style=" font-size:11pt;font-family:Calibri"> </span>
<br><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>
<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>