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

Wed Mar 31 15:53:13 UTC 2021

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.

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:

[cid:image001.gif at 01D724B1.7D12E2C0]
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 direction."

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

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.

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.

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.

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

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:

[cid:image002.gif at 01D72551.FC279470]
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, 2009.
NOTE - ETSI standards are available for free download at http://www.etsi.org.

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 (2020-08).

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.

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?

C.     VCM Protocol (CCSDS 431.1-B-1, February 2021)

Figure 2-1 of the VCM Protocol Blue Book is:

[cid:image003.gif at 01D72620.E0372BC0]
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.

Regarding the VCM Protocol itself, the blue book specifies three sets of  "modes":

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

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

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.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210331/043f0b8b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 29163 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210331/043f0b8b/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 18934 bytes
Desc: image002.gif
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210331/043f0b8b/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 23440 bytes
Desc: image003.gif
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210331/043f0b8b/attachment-0005.gif>