[Sea-sa] SLS comments to slide 9 and 10 of "SEA High Rate comm issue 1Mar21.pptx": Background materials for today's SEA-SA SCCS-ARD discussion

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Mar 9 15:45:33 UTC 2021


[attachment "Spaghetti2021.ppt" deleted by Gian Paolo Calzolari/esoc/ESA] 
Dera Peter,
        here attached SLS comments to slide 9 and 10 of "SEA High Rate 
comm issue 1Mar21.pptx"
We focused on those two slides because of the diagrams that are addressing 
books produced in SLS.
Absence on comments on other slides or other parts of your mail does not 
imply SLS agreement.
The two original slides are attached here below for easier reference.

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.

Nevertheless some focused comments were gathered and they are reported 
below.

-----------------------------------------------------------------------------
SLIDE 9 - Current CCSDS Layered Protocol Stack, with CNES & ESA “add-ons” 
shown
1) The box Encapsulation service shall be renamed Encapsulation Packet 
protocol 
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. 
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) 
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. 
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. 
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. 
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. 
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 
https://public.ccsds.org/Pubs/131x2b1e1.pdf  while in 
https://public.ccsds.org/Pubs/131x3b1.pdf it is used only to explain the 
unused acronym OID). 
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". 
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" 
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. 
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 https://public.ccsds.org/Pubs/231x0b3.pdf 

------------------------------------------------------------------
SLIDE 10 - Detail of SCCC and DVB-S2 “integratedData Link and Physical 
Layers
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.
2) On the left side of the drawing, the label  "Data Link Layer" shall be 
replaced by " Data Link Protocol Sublayer"
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" 
4) The SCCC and DVB-S2 boxes shall have the same height.
5) The SCCC box height shall not exceed into the Data Link Protocol 
Sublayer
6) The DVB-S2 box height shall not exceed into the Data Link Protocol 
Sublayer
7) The Space Data Link Protocols perform no slicing. The box "Slice" in 
SDLP box  (upper right corner of the drawing)shall be removed.
8) The "Fill frames" box  in the SDLP box (upper right corner of the 
drawing)  shall be renamed "OID Frames"
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 Greg and Matt.
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.
11) in the TM S&CC box, it could be good adding something showing the 
concatenated codes.
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."
13) In the RF & Mod Box, does the "Filter" box make sense?
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.
15) The statement "Parallel to “main-line” CCSDS standards from data link 
down" it is not clear.
16)  SLS strongly disagree with the stated issue "These agency unique, 
down-link only,  approaches are not truly interoperable with each other 
nor with the rest of CCSDS". What does it mean " interoperable with each 
other "? 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.
17) The added comment "And they are now being proposed as suitable for 
downlink, uplink, and cross-link for all deployments, including Lunar and 
deep space" is irrelevant and forgets that such a proposal has been 
accepted by the WG and even by CMC that approved the relevant projects.
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.
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.
------------------------------------------------------------------------

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.
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.
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)..

I hope I succeeded in reporting correctly and honestly the interaction 
with the other SLS Players.

Best regrads

Gian Paolo

(*) As Ken distributed two versions with the same name, I renamed the 
latest one to show the full date. The contents are untouched.







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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210309/0b02dae2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEA High Rate comm issue 1Mar21(pages9+10).pdf
Type: application/octet-stream
Size: 257493 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210309/0b02dae2/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Spaghetti20210309.ppt
Type: application/octet-stream
Size: 786944 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210309/0b02dae2/attachment-0003.obj>


More information about the SEA-SA mailing list