[Sea-sa] Correction / Table 6-8: Background materials for today's SEA-SA SCCS-ARD discussion
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Thu Mar 11 13:09:41 UTC 2021
It looks I did not complete part of the text about my comment on some
misunderstanding about the handling of VCM (intended as methods and not as
431.0-B) and ACM.
Please amend the relevant text as follows:
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.
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.
What changes between VCM and ACM is how the transmitter is instructed to
apply changes of ModCod; e.g. normally pre-programmed in VCM and with
feedback from the receiving side in ACM.
A ModCod may remain constant for days. weeks, months (e.g. based on
seasons, whether forecast, etc.) or change "more frequently" even during
the same pass.
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.
Best regards
Gian Paolo
From: Gian.Paolo.Calzolari at esa.int
To: "Shames, Peter M\(US 312B\)" <peter.m.shames at jpl.nasa.gov>
Cc: "Lee, Dennis K\(US 332G\)" <dennis.k.lee at jpl.nasa.gov>,
Gilles.Moury at cnes.fr, "Andrews, Kenneth S\(332B\)"
<Kenneth.S.Andrews at jpl.nasa.gov>, Enrico.Vassallo at esa.int, "SEA-SA"
<sea-sa at mailman.ccsds.org>
Date: 10-03-21 16:09
Subject: [Sea-sa] Table 6-8: Background materials for today's
SEA-SA SCCS-ARD discussion
Sent by: "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>
Dear Peter,
please find here attached a few comments on the two files
addressing Table 6-8 and the “cheat sheet” of notes that encode the
cells in this table.
About the "separations" you mentions, the following is understood (with no
comment now):
A) uplink is separate from downlink ==> RAF, RCF, and ROCF columns refer
to downlink, F-CLUTU and FF-CSTS columns refer to uplink
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
C) 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 ==> two rows
are dedicated to SCCC and DVB-S2 standards
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 “bottom” 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).
With respect to VCM (now published) it does not look correct to me to
state that it is related to the “bottom” parts of the DVB and SCCC
specs.
Actually it should be considered having an equivalent behaviour to SCCC
and DVB-S2.
However let's look at the table row by row (more or less).
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.
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.
3) Fixed Length USLP - What is R3?
4) TC SDLP - the box for RAF shall be empty.
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?
6) Why the second sentence of N5 refers to RAF and not to CLTU?
7) VCM - Which O? I think that VCM can also use HOMs and should be treated
as SCCC and DVB-S2
The reading and evaluation of this Table is very painful and confusing
and most likely other comments could easily be produced.
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.
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.
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.)
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.
Best regards
Gian Paolo
From: "Shames, Peter M\(US 312B\) via SEA-SA"
<sea-sa at mailman.ccsds.org>
To: "SEA-SA" <sea-sa at mailman.ccsds.org>
Date: 02-03-21 23:37
Subject: [Sea-sa] Background materials for today's SEA-SA SCCS-ARD
discussion
Sent by: "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>
[attachment "431x1b0_CESG_Approval.pdf" deleted by Gian Paolo
Calzolari/esoc/ESA]
Dear SCCS-ARD sub-team,
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.
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.
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.
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.
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.
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 “variable coded modulation,
VCM: 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.
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.
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.
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.
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.
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:
NOTE ‐
Changes of the value of the information block size K 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).
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.
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.
1. The “CCSDS standard” suite of link layer, coding,
synchronization, modulation, and RF standards
2. A subsection on the Optical coding and modulation standards that
slot in underneath the normal link layer protocols, along with a brief
description
3. 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.
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.
Thanks, Peter
_______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa
[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]
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 at esa.int).
_______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa
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 at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210311/002b6a67/attachment-0001.htm>
More information about the SEA-SA
mailing list