[Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Apr 6 22:43:21 UTC 2021

        after some coordination  with other SLS representatives, please 
find here below mixed in your text (marked in bold red  and starting with 

Further clarifications may follow.

Best regards

Gian Paolo

PS Please consider that Monday 6 April was a Public Holiday in most of 

From:   "John Pietras" <john.pietras at gst.com>
To:     "sea-sa at mailman.ccsds.org" <sea-sa at mailman.ccsds.org>
Date:   31-03-21 17:53
Subject:        [Sea-sa] Notes on VCM, DVB-S2, and SCCC
Sent by:        "SEA-SA" <sea-sa-bounces at mailman.ccsds.org>

SEA-SAWG colleagues ---
I’ve been wading through the Flexible Advanced Coding and Modulation 
Scheme for High Rate Telemetry Applications Blue Book (CCSDS 131.2-B-1, 
March 2012, hereinafter referred to as SCCC [for Serial Concatenated 
Convolutional Code]), CCSDS Space Link Protocols Over ETSI DVB-S2 Standard 
(CCSDS 131.3-B-1, March 2013, hereinafter simply referred to as 
CCSDS/DVB-S2), and Variable Code Modulation Protocol (CCSDS 431.1-B-1, 
February 2021) and comments from reviewers of the ARD table 6-8, trying to 
understand the relationships among these various VCM schemes. 
This email recaps my observations and the questions that my reading has 
raised. Ultimately my concern is to be able to represent this area 
correctly (albeit abstractly) in the SCCS-ARD. I would very much 
appreciate any feedback about the correctness of my interpretations.
>>> SLS do appreciate do appreciate your concern to correctly represent 
A.     SCCC (CCSDS 131.2-B-1, March 2012)
The SCCC protocol stack diagram  (figure 2-1) indicates the it covers the 
CCSDS Sync and Channel Coding Sublayer and the Physical Layer:

An introductory paragraph that precedes this diagram states “The 
Synchronization and Channel Coding Sublayer provides methods of
synchronization and channel coding for transferring Transfer Frames over a 
space link while the Physical Layer provides the RF and modulation methods 
for transferring a stream of bits over a space link in a single 
However, the SCCC specification addresses only some aspects of the 
Physical Layer -  specification of the five modulation schemes to be used 
as part of SCCC:
1)     QPSK (specified by cross reference to the appropriate definition in 
CCSDS 401.0):
2)     8PSK
3)     16APSK
4)     32APSK
5)     64APSK
and coding rates.
The “RF” aspects of the Physical Layer of a space link (frequency bands, 
polarization, etc., etc.) are not mentioned at all. So the protocol stack 
diagram is at least partially misrepresentative. There should be another 
“RF Physical sublayer” under the Flexible Advanced Coding and Modulation 
Scheme for High Rate Telemetry Applications “layer”. But this raises 
another issue – what CCSDS Blue Books (or what parts of what CCSDS Blue 
Books) would constitute such an RF Physical sublayer? CCSDS 401.0 is 
referenced, but only with respect to the specification of QPSK modulation. 
Is it assumed that 401.0 supplies the underlying RF functions? CCSDS also 
has CCSDS 415.1 (Data Transmission and PN Ranging for 2 GHz CDMA Link via 
Data Relay Satellite) – is SCCC viable for use over 415.1 links? [Note – 
the SCCS-ARD does not include CCSDS 415.1 because it is currently used 
only for the NASA TDRSS-based Space Network. But the authors of the SCCC 
book should not ignore the implications for use of SCCC over something 
other than 401.0, and how to address such possible wider usage in the SCCC 
blue book.]
>>> Indeed 401.0-B ( https://public.ccsds.org/Pubs/401x0b31.pdf ) contains 
other regulations in addition to modulations. This is visible in section 
1.4 DOCUMENT FORMAT. By convention those other conventions are never 
mentioned explicitly in the standards referring to 401.0-B. It is clear 
that modulations are not used ignoring the rest of the regulations and 
this is considered implicit and it has never given implementation 
>>> SCCC in NOT intended for use over 415.1 links. In fact, that book is 
not mentioned in SCCC.
Some other observations:
a)     The book – written in 2012 – normatively references only the TM and 
AOS space data link protocols. SCCC depends on the use of the Frame Error 
Control Field (as defined in the TM and AOS SDLPs) to perform Frame 
Validation. SCCC is also expected to be used to carry fixed-length USLP 
frames, so USLP (at least the specification of the FECF in the USLP frame) 
is normative on the SCCC. >>> SCCC is going to add USLP Frames and the 
normative references will be listed together with TM SDLP and AOS. Andrea 
Modeninini as book Editor is preparing the relevant draft.
b)     In section 2.3 (Internal Organization), the document describes the 
Sending End (section 2.3.1) using diagrams of the individual functions 
involved and the “stream format at different stages of process”. However, 
the description of the Receiving End (2.3.2) consists of “At the receiving 
end, the Synchronization and Channel Coding Sublayer accepts a continuous 
and contiguous stream of physical channel symbols, performs functions 
selected for the mission, and delivers Transfer Frames to the Data Link 
Protocol Sublayer.” Besides saying nothing about how this is done, this 
description is inconsistent with the declared scope of SCCC as performing 
functions in in the Physical Layer as well as the Synchronization and 
Channel Coding Sublayer. >>> In a few cases some remarks on the receiving 
side are mentioned when relevant, however, specification of receivers is 
not part of our standards. The output at the sending side shall be unique 
while at the receiving side several algorithm can be used to correctty 
process the received stream. This is valid for decoding, demodulation, 
decompression, decrypt, etc.  >>> However you are correct, the book will 
mention that also the receiving side performs functions in in the Physical 
Layer and in the Synchronization and Channel Coding Sublayer. 
c)     Section 7.1.1 states “Frame synchronization is necessary for 
subsequent processing of the Transfer Frames. Furthermore, it is necessary 
for synchronization of the pseudo-random generator, if used (see section 
8).} [italicization mine]. Section 8.1 states “The Pseudo-Randomizer 
defined in reference [1] is always required by SCCC”. The “if used” 
qualifier in 7.1.1 seems superfluous since 8.1 says that it must be used, 
and could lead to misunderstanding that randomization might be optional.  
>>> Andrea Modeninini as book Editor is preparing the relevant draft and 
will take of this editorial improvement.
d)     This is a nit-pick, but the acronyms “PSK”, “QPSK”, and “APSK” are 
never spelled out or listed in the acronym list. I already knew what “PSK” 
and “QPSK” stood for, but had to Google “APSK” to get “amplitude and phase 
shift keying”.  >>> Andrea Modeninini as book Editor is preparing the 
relevant draft and will take of this editorial improvement together with 
Tom Gannett for completing the list of acronyms.
I see from the CCSDS Framework that an update to this document is 
underway. Perhaps these comments will be useful  to the C&S WG.
B.     CCSDS/DVB-S2 (CCSDS 131.3-B-1, March 2013)
The following figure is presented in the Blue Book to relate the functions 
defined in the CCSDS/DVB-S2 Blue Book to the OIS and CCSDS layered models:

Other than the relatively-simple “CADU Stream Generation” sublayer, the 
great majority of the functionality of this book is specified by reference 
to the DVB-S2 specification that was in effect as of the time of 
specification of this Recommended Standard, which is given in the 
normative References as
[1]  Digital Video Broadcasting (DVB); Second Generation Framing 
Structure, ChannelCoding and Modulation Systems for Broadcasting, 
Interactive Services, News Gathering and other Broadband Satellite 
Applications. ETSI EN 302 307 V1.2.1 (2009-08). Sophia-Antipolis: ETSI, 
NOTE – ETSI standards are available for free download at 
In attempting to use the link to obtain a copy of the document, I searched 
on the document number (ETSI EN 302 307 V1.2.1). There was no document 
with this number available, but three with variations on the number: 
-        DVB-S2: ETSI EN 302 307 V1.3.1 (2013-03),
-        DVB-S2, Part1, DVB-S2: ETSI EN 302 307-1 V1.4.1 (2014-11), and 
-        DVB-S2, Part2, DVB-S2 Extensions: ETSI EN 302 307-2 V1.2.1 
My interpretation is that the Part 1 (2014) and Part 2 (2020) versions are 
replacements for the 2008 and 2013 DVB-S2 (no parts) version and update 
(respectively), although the documents don’t say that in so many words. 
Without a better understanding of the applicable technologies, I am unable 
to determine (or even guess) which Parts (1, 2, or both) are applicable to 
the use of DVB-S2 for the encoding and transmission of CCSDS SDLP frames. 
>>> CNES has prepared an updated document that should start soon Agency 
Review.  The CMC Approval versuon still refernces ETSI EN 302 307 V1.2.1. 
I think that the standard is really intended for use with V1.2.1 and not 
with later versions.
I am unable to say for certain, but it also appears that neither the Part 
1 nor the Part 2 specifications address complete set of RF requirements to 
a level similar to that found in CCSDS 401.0. If my impression is correct 
in this respect, as with the SCCC book it is somewhat incorrect to imply 
that the DVB-S2 specifications address all aspects of the Physical Layer, 
as is implied by Figure 2-1 (copied above). Again, should there be some 
“RF Physical sublayer” under the DVD-S2 transmission sublayer? And if so, 
are some subset of functions defined in CCSDS 401.0 assumed to satisfy the 
requirements for that RF Physical sublayer? What about DVB-S2 “over” CCSDS 
415.1 links?
>>> Please consider the SCCC reply above for 401.0-B.  
C.     VCM Protocol (CCSDS 431.1-B-1, February 2021)
Figure 2-1 of the VCM Protocol Blue Book is:

Note that the “SMTF Stream Generation” function/sublayer is exactly the 
same as the “CADU Stream Generation” function/sublayer of the CCSDS/DVB-S2 
Blue Book: “SMTF” is the more-appropriate term for a transfer frame that 
is pre-pended with an ASM, whereas “CADU” in general allows the 
possibility of intermediate encoding being applied before the ASM.  >>> 
C&S WG may consider using a uniform term. Andrea & Ken may consider thois 
point of discussion.
Regarding the VCM Protocol itself, the blue book specifies three sets of 
-        Modes that apply to CCSDS Turbo and LDPC encoding (a subset of, 
and as defined in, CCSDS 131.0-B). These are the “TM” codes;
-        Modes that apply to SCCC encoding. These modes are “consistent 
with the existing specification of codes, modulations, and VCM protocol 
given in references [2] [SCCC Blue Book] and [5] [CCSDS 401.0]”; and
-        Modes that apply to CCSDS DVB-S2 encoding.  These mode are 
“consistent with the existing specification of codes, modulations, and VCM 
protocol given in references [3] [CCSDS/DVB-S2], [4] [the 2014 version of 
DVB-S2: Part 2], and [5] [CCSDS 401.0]”.
Type 2 VCM has a set of modes that apply to CCSDS Turbo and LDPC coding 
schemes (as defined in CCSDS 131.0-B) and a different set of codes for 
DVB-S2. The difference between Type 1 and 
The VCM BB defines two VCM protocol “Types”: Type 1 and Type 2. The two 
Types differ in the values for the parameters H (the length of the PLFRAME 
header, S (the number of codeword modulation symbols between pilot symbol 
blocks), and P (the number of modulation symbols present in each optional 
symbol block). Type 1 uses the H/S/P values that have already been defined 
in the SCCC Blue Book, and Type 2 uses the H/S/P values that have already 
been defined in the CCSDS/DVB-S2 Blue Book and the ETSI DVB-S2: Part 2 
What the VCM Blue Book specifies uniquely is the use of TM Turbo and LDPC 
encoding, which is defined for both VCM Type 1 and VCM Type 2. However, 
the material regarding SCCC encoding and DVB-S2 encoding appears to me to 
be simply a restatement of existing material that is already normatively 
stated in the SCCC Blue Book, CCSDS/DVB-S2 Blue Book, and the ETSI DVB-S2: 
Part 2 standard. Is there is something that the VCM Protocol BB adds to 
the existing standards? >>>  The 431.1-B VCM standard does not alter the 
specification of the 131.2-B and 131.3-B VCM protocols. This means that a 
user of SCCC or DVB-S2 codes compliant with 131.2-B or 131.3-B will also 
comply with 431.1-B. The 431.1-B book puts the VCM protocol under a common 
umbrella to help explain how to use TM codes with either of the SCCC or 
DVB-S2 approaches to VCM. This has the side benefit of showing that there 
really is one common VCM approach in CCSDS..
The fact that the VCM Protocol book restates and in a sense co-opts the 
SCCC and CCSDS/DVB-S2 Blue Books can lead to ambiguity. 
>>>  This situation is no different than the 401.0-B incorporating the 
definitions of the higher order modulations which are already described in 
131.2-B and 131.3-B. They are the same, so there is no ambiguity.
When one refers to “CCSDS VCM”, should that be interpreted as a blanket 
reference to “TM VCM”, SCCC VCM, and DVB-S2 VCM, or do we want to continue 
to cull out the different flavors separately? For the purposes of the 
SCCS-ARD, we might want to just use “CCSDS VCM” to collectively refer to 
all flavors, with a single reference to CCSDS 431.1, and have a separate 
(simple, high-level) “discussion” of the components of that collective 
protocol. That will certainly make the tables in the ARD simpler. >>> 
Agreed. There really is only one approach to VCM in CCSDS. OK for SCCS-ARD 
to just use “CCSDS VCM” to collectively refer to all flavors. However 
referincg may better include all the books for those willing to look at 
the details .
Finally, as with the SCCC and CCSDS/DVB-S2 blue books, the VCM Protocol 
Blue Book does not address the RF aspects of the Physical Layer. The same 
questions apply about whether an RF Physical sublayer should be called 
out, whether and what aspects of CCSDS 401.0 meet the requirements for 
such a sublayer, and whether other space link physical layer 
specifications (such as CCSDS 415) can be used for VCM. >>> Please 
consider the SCCC reply above for 401.0-B.  
Best regards,
SEA-SA mailing list
SEA-SA at mailman.ccsds.org

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/20210407/8def98d9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 29163 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210407/8def98d9/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 18934 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210407/8def98d9/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 23440 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210407/8def98d9/attachment-0005.gif>

More information about the SEA-SA mailing list