[Sea-sa] [EXTERNAL] It is a smaller sandwich: Background materials for today's SEA-SA SCCS-ARD discussion
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Fri Mar 5 09:48:18 UTC 2021
Peter,
I am not running a one man show but coordinating with other SLS
players to provide an SLS agreed set o comments.
As you can understand this takes some time.
Regards and have a nice week end
Gian Paolo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "SEA-SA" <sea-sa at mailman.ccsds.org>, "SLS - Space Link Services
Area" <sls at mailman.ccsds.org>
Date: 04-03-21 23:30
Subject: Re: [EXTERNAL] It is a smaller sandwich: [Sea-sa]
Background materials for today's SEA-SA SCCS-ARD discussion
Hi Gippo,
Thanks for the allusion to Scheherazade. Perhaps you also want to
reference the “Dance of the Seven Veils (layers)”?
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.
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.
That said, please do take the time to chew on the draft materials we
provided and provide feedback.
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, March 4, 2021 at 1:43 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>, SLS - Space Link Services Area
<sls at mailman.ccsds.org>
Subject: Re: [EXTERNAL] It is a smaller sandwich: [Sea-sa] Background
materials for today's SEA-SA SCCS-ARD discussion
Dear Peter,
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".
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.
I think we shall ensure consistency in CCSDS and therefore I stick to
CCSDS books.
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>.
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.
In one case we have splitting, in the other one we have "characterization
(according to physical characteristics)".
Can you please define what you call < “normal” CCSDS standards>?
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.
Usually there is a mixing of managed and inline parameters. Just to
mention an example, https://public.ccsds.org/Pubs/732x0b3e1.pdf uses in
the Frame Header a Virtual Channel identifier and even a "Signaling
Field".
Actually, USLP ( https://public.ccsds.org/Pubs/732x1b1.pdf ) goes further
and - as you know - Greg proudly remarks that USLP increases the number of
signalling fields.
Indeed the 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.
Other diagrams in the various standards clarify the details that have
nothing to do with layering.
My conclusion is that all CCSDS Standards are "normal" CCSDS Standards and
include both managed parameters and inline parameters.
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.
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 (
https://en.wikipedia.org/wiki/Robert_G._Gallager ) in 1960 when their
implementation was unrealistic for the technology available at that time -
do show.
This closes my discussions on layering.
Otherwise I confirm my statement: 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.
Best regards
Gippo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "SEA-SA" <sea-sa at mailman.ccsds.org>, "SLS - Space Link Services
Area" <sls at mailman.ccsds.org>
Date: 03-03-21 23:08
Subject: Re: [EXTERNAL] It is a smaller sandwich: [Sea-sa]
Background materials for today's SEA-SA SCCS-ARD discussion
Hi Gippo,
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).
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.
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.
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.
Is that something you can do?
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.
It would be good to get your feedback to make sure that we represent all
of this accurately.
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, March 3, 2021 at 10:18 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>, SLS - Space Link Services Area
<sls at mailman.ccsds.org>
Subject: [EXTERNAL] It is a smaller sandwich: [Sea-sa] Background
materials for today's SEA-SA SCCS-ARD discussion
Dear Peter,
I must say that I am quite puzzled by this mail.
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.
Here, after a check with SLS colleagues, I want to comment on your
statement about the “3-layer sandwich” .
Indeed that sandwich is not so big as you claim.
Actually all the following documents
https://public.ccsds.org/Pubs/131x2b1e1.pdf
https://public.ccsds.org/Pubs/131x3b1.pdf
https://public.ccsds.org/Pubs/431x0b1.pdf
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).
They all also show this (even with some minor differences) in their
"Figure 2-1: Relationship with OSI Layers" showing together the
1) Synchronization and Channel Coding Sublayer that provides methods of
synchronization and channel coding for transferring Transfer Frames over a
space link and the
2) Physical Layer that provides the RF and modulation methods for
transferring a stream of bits over a space link in a single direction
For reference the three figures are attached as snapshots.
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).
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).
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/20210305/a384ad23/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 29165 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210305/a384ad23/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 18936 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210305/a384ad23/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 23442 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210305/a384ad23/attachment-0005.gif>
More information about the SEA-SA
mailing list