[Sea-sa] [EXTERNAL] Clarification: SLS reply: Notes on VCM, DVB-S2, and SCCC
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Wed Apr 21 11:26:05 UTC 2021
Peter,
I want to be short.
I do not question the value of this document but... est modus in rebus.
Making this document more normative that the mentioned blue books (as it
appears from your remarks) is not going in the right direction IMO.
Best regards
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: "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, "Dudal
Clement" <Clement.Dudal at cnes.fr>, "Lee, Dennis K (US 332G)"
<dennis.k.lee at jpl.nasa.gov>, "Enrico.Vassallo at esa.int"
<Enrico.Vassallo at esa.int>, "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>,
"EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras at gst.com>,
"Hamkins, Jon (US 3300)" <jon.hamkins at jpl.nasa.gov>, "Andrews, Kenneth S
(US 332B)" <kenneth.s.andrews at jpl.nasa.gov>, "sea-sa at mailman.ccsds.org"
<sea-sa at mailman.ccsds.org>
Date: 13-04-21 22:20
Subject: Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes
on VCM, DVB-S2, and SCCC
Hi Gippo,
I’m sorry if you misunderstand the intent, and no, we are not, as Nestor
sometimes suggested “Trying to be more Catholic than the Pope.” What we
are trying to do is to provide guidance for the users of CCSDS standards
as to how “Tab A fits into Slot B”. In the process of trying to do that
in a way that is understandable we have encountered all sorts of special
cases, “if this, then not that”, “only in this case, not in that case”,
and special dispensations. We did not make these things up, we read the
docs and discovered them. And so we are asking you guys for cross-checks
“did we understand this correctly?” and in some cases for clarifications,
as in “can we say this differently to be clearer?”.
I believe that you understand that while this is a “space communication
cross support architecture” that it is not now, and never has been, just
about “cross support” in any narrow sense. It has always covered four of
the six CCSDS Areas of work: SLS, SIS, CSS, and SEA. And it is about
mission systems (EUN) to ground station (ESLT), and from ground station
(ESLT) to spacecraft (SUN), for basic “single space link” or ABA missions
and for more complex, internetworked or relayed architectures (SSI). This
is “cross support” in the broadest, end-to-end, sense, including security
considerations.
We all have our own points of view, and they differ. That, as they say,
is what makes a horse race. I do have to be amused that the one “oh yes,
this doesn’t work” topic for FF-CSTS is precisely, from my point of view,
the only reason why we really needed FF-CSTS in the first place. That was
to provide coding in the ESLT for a stream of frames, and the “plumbing”
to merge (and then encode) multiple streams of frames in the ESLT. Without
those features, and the related coding for uplink / forward AOS and USLP,
we really did not need to invest in creating FF-CSTS at all. Not having
this is not just “some limitation”, it is the raison d’etre for FF-CSTS.
It does remain to this architecture document to describe how all of these
many parts fit together. And some of these parts, as you know, don’t fit
particularly well, or it’s like a jigsaw puzzle with some missing pieces,
others that need to be filed down a bit to fit, and others where there are
three or more mostly identical pieces that sort of all fit the same …
mostly. There is no other single place in CCSDS where you can find the
sort of integrated views of this broad collection of information that the
SCCS-ARD provides.
I really do not know why you would question the value of this document,
but, of course, this is my own opinion and perception.
Cheers, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Friday, April 9, 2021 at 3:41 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, Dudal Clement
<Clement.Dudal at cnes.fr>, Dennis K Lee <dennis.k.lee at jpl.nasa.gov>,
"Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>, Gilles Moury
<Gilles.Moury at cnes.fr>, John Pietras <john.pietras at gst.com>, Jon Hamkins
<jon.hamkins at jpl.nasa.gov>, Kenneth Andrews
<kenneth.s.andrews at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Subject: Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM,
DVB-S2, and SCCC
Peter,
frankly speaking I am quite puzzled by this kind of inquiring.
It looks as you want to go to a level of detail even bigger than 401.0-B
instead of simply referencing that book
This is giving me a strange (and uncomfortable) perception (*) like you
want either rewrite 401.0-B or teach RFM WG how to write it.
(*) perception is clearly something personal..
If you think that a new “RF Physical Sublayer” is really required together
with other "corrections" to that book, I strongly recommend you address
all that to the RFM WG in the form of a formal input paper (you may still
be on time for Spring 2021 Meetings).
On my side I am really puzzled by the level of details you want to enter
in your document, specially considering the focus on cross support
services where (just to say something also with respect to available cross
support service) I think we can easily affirm as a matter of fact that
- SLE RAF can be used with any of the three 131.x standards
- SLE RCF can be used with any of the three 131.x standards
- SLE ROCF can be used with any of the three 131.x standards
- SLE CLTU can be used ONLY with TC Coding
- CSTS Forward Frame can be used with 231.0 (TC) standards and it can be
used with any of the three 131.x standards (*)
(*) only exception I understand should be some imitation for the "FF-CSTS
Provider (CADUs)" with respect to the coding options performing encoding
of SMTF streams
It looks as there is an attempt of having an architecture document more
normative than the normative standards. Is this really a good idea?
Of course this is my personal perception and opinion.
Best regards
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: "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, "Dudal
Clement" <Clement.Dudal at cnes.fr>, "Lee, Dennis K (US 332G)"
<dennis.k.lee at jpl.nasa.gov>, "Enrico.Vassallo at esa.int"
<Enrico.Vassallo at esa.int>, "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>,
"EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras at gst.com>,
"Hamkins, Jon (US 3300)" <jon.hamkins at jpl.nasa.gov>, "Andrews, Kenneth S
(US 332B)" <kenneth.s.andrews at jpl.nasa.gov>, "sea-sa at mailman.ccsds.org"
<sea-sa at mailman.ccsds.org>
Date: 07-04-21 20:54
Subject: Re: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes
on VCM, DVB-S2, and SCCC
Hi Gippo,
I understand now that you meant the reference to be to the 401.0 BB and
not to dismiss the 415.1 reference. Thanks.
But I still do not think that the highlighted paragraph addresses the
specific aspect of the questions that John raised:
“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?”
As we understand it, the RF&M document, the 401.0 BB, includes aspects
that address modulations, data rates (coded symbol rates), frequencies,
and directions, as well as aspects covered by regulations (ITU),
conventional usages, and even implementation constraints. As such there
are really separate ISO BRM Layer 1 “sub-layers” that are being addressed.
Modulation is the most obvious one, but these other “sub-layers”, or
aspects, play a strong part in the complexity of the 401.0 spec which
tends to be narrowly parsed into segments like:
2.4.18 MODULATION METHODS AT HIGH CODED SYMBOL RATE TRANSMISSIONS, EARTH
EXPLORATION SATELLITES (EES) 8 GHZ BAND, SPACE-TO-EARTH
This addresses, very narrowly, a specific frequency band (8 GHz), a class
of spacecraft (EES), a direction (Space-to-Earth), and a specific subset
(HOM) of all the possible modulations. As you all know, this is only one
of many such narrowly parsed segments. We know that there are technical
as well as regulations, conventions, and technical limitations that
motivate this particular construction of this standard.
But here is the underlying question that John’s “all aspects of the
Physical Layer” question was trying to get at. Is it correct to state
that SCCC, or DVB, just can use all of the possible 401.0 modulations,
frequency bands, data rates, and directions, or is it only a sub-set of
them? In particular, with DVB-S2, which was designed for near Earth
high-rate, downlink from HEO satellites, is it accurate to just state “it
can use all of the 401.0 defined modulations, etc”? Or do the DVB and
SCCC VCM approaches really assume something else, or state something else
in terms of their expectations as to which parts of the 401.0 book are
applicable? Which frequencies, data rates, and directions? We were not
able to find these linkages, but maybe we were just not looking in the
right places.
In terms of how to diagram the relationships between the VCM books, as a
set, and the 401.0 book it also occurred to us that the references to the
RFM book, in the context of VCM, is sort of like referencing specific
parts, of parts, of the 401.0 book from inside the VCM books. It appears
that there is a part of the 401.0 book that is inside the CODMOD pairs in
the VCM spec and a part of it that is in a sense outside the CODMOD VCM
spec, in the FM & FD “layer”. So in some ways the 401.0 book is “inside”
the VCMs and not “under” them. This seems almost analogous to the sort of
“tunneling” constructs that sometimes show up in network layer constructs
with the use of VPNs, or when BP is tunneled in IP. Those are “network
layer inside network layer”. There is a certain set of more or less
“standard” configurations and others that are not normally used.
All of these questions came up as we were reading through this set of
documents and trying to “connect all of the dots”. Similar sorts of
questions arose when thinking through the question of how to do ranging,
and Delta-DOR, with the Higher Order Modulations (HOM) that are featured
in SCCC and DVB, and also now in the VCM and 401.0 books.
We think some clear statements to disambiguate all of this will be very
useful to the readers of the SCCS-ARD and the documents it references.
Is the basis for this question more clear now? Perhaps that reference to
“RF Physical Sublayer” was too vague?
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, April 6, 2021 at 11:14 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, Dudal Clement
<Clement.Dudal at cnes.fr>, Dennis K Lee <dennis.k.lee at jpl.nasa.gov>,
"Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>, Gilles Moury
<Gilles.Moury at cnes.fr>, John Pietras <john.pietras at gst.com>, Jon Hamkins
<jon.hamkins at jpl.nasa.gov>, Kenneth Andrews
<kenneth.s.andrews at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Subject: [EXTERNAL] Clarification: [Sea-sa] SLS reply: Notes on VCM,
DVB-S2, and SCCC
Peter,
just a quick clarification.
In a few places where it is stated:
>>> Please consider the SCCC reply above for 401.0-B
as the statement “>>> SCCC in NOT intended for use over 415.1 links. In
fact, that book is not mentioned in SCCC." refers to 415.1 and not to
401.0-B, the correct reference is the following one
----------------------
>>> 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
problems.
----------------------
You may want to review your other assertions below according to this.
I guess this will help everybody and specially the SLS readers.
Best regards
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>,
"EXTERNAL-Pietras, John V (US 332C-Affiliate)" <john.pietras at gst.com>
Cc: "Dudal Clement" <Clement.Dudal at cnes.fr>,
"Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int>, "Lee, Dennis K (US
332G)" <dennis.k.lee at jpl.nasa.gov>, "Hamkins, Jon (US 3300)"
<jon.hamkins at jpl.nasa.gov>, "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>,
"Andrews, Kenneth S (US 332B)" <kenneth.s.andrews at jpl.nasa.gov>,
"Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>,
"sea-sa at mailman.ccsds.org" <sea-sa at mailman.ccsds.org>
Date: 07-04-21 01:47
Subject: Re: [EXTERNAL] [Sea-sa] SLS reply: Notes on VCM, DVB-S2,
and SCCC
Hi Gippo,
Thanks for the replies. It is helpful to keep up this collegial dialogue
as we try and sort out the complexities. John may have some comments of
his own, and I have some materials from our SEA-SA meeting of yesterday
that I will share with all of you once I send this brief note off.
In a few places you stated:
>>> Please consider the SCCC reply above for 401.0-B
I am puzzled by some of these references. If you mean only to point to
the statement “>>> SCCC in NOT intended for use over 415.1 links. In fact,
that book is not mentioned in SCCC.” then this reference makes sense. We
understand that the 415.1 spec is rather a “stand-alone” standard. It is
not clear that we even need to include it in this document unless there is
a strong requirement to do so.
For the others:
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.
I think that this “reply for 401.0-B” is only relevant to the 415.1 part
of this, and not to the rest of this statement relating to the
relationships between the SCCC and the physical sub-layer aspects of the
401.0 spec.
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.
Here too, I believe that the 415.1 part of this is accurate, but that this
leave unanswered the question about the relationships between DVB and the
physical sub-layer aspects of the 401.0 spec. . The 401.0 spec, as you
are aware, is a thicket of “if this, then that, but not that” kinds of
statements. And it has finely parsed clauses about specific frequency
bands, modulations, data rates, ranging (or not), and directionality. And
SCCC (and DVB) both include 401.0 modulations and somehow subsume them
inside the frame of pilot symbols. It’s not clear from either the SCCC or
DVB specs just which of the possible physical sub-layer and directionality
parts of the 401.0 spec are applicable.
Can you and your SLS Area team help to clarify these questions?
In the context of the 431.0 spec, and its relationship to SCCC and DVB,
this occurs:
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..
I agree that the 431.0 spec puts all three of the related VCM options
under one umbrella, and that this helps the reader to understand the
similarities, and differences, among these protocols stacks. And it
appears to be the case that a use of SCCC or DVB will, because of the
structure of this document, be compliant with the 431.0 spec. That said,
it is also true that an implementation of SCCC will not be compliant with
DVB, nor will an implementation of DVB be compliant with SCCC, nor, for
that matter, with the one using the CCSDS TM code options. There is not
really “one common VCM approach” in CCSDS, there are three, with some
complex overlaps and interconnections that this book helps to clarify, but
cannot dispel.
We do hope to add just enough clarifying material in the SCCS-ARD to make
this as clear as we can. And we will need you help to ensure that this is
as clear as it can be. Please look at the next set of materials I will
send and let us know what you think.
Thanks, Peter
From: SEA-SA <sea-sa-bounces at mailman.ccsds.org> on behalf of Gian Paolo
Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, April 6, 2021 at 3:43 PM
To: John Pietras <john.pietras at gst.com>
Cc: Dudal Clement <Clement.Dudal at cnes.fr>, "Andrea.Modenini at esa.int"
<Andrea.Modenini at esa.int>, Dennis K Lee <dennis.k.lee at jpl.nasa.gov>, Jon
Hamkins <jon.hamkins at jpl.nasa.gov>, Gilles Moury <Gilles.Moury at cnes.fr>,
Kenneth Andrews <kenneth.s.andrews at jpl.nasa.gov>,
"Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int>, SEA-SA
<sea-sa at mailman.ccsds.org>
Subject: [EXTERNAL] [Sea-sa] SLS reply: Notes on VCM, DVB-S2, and SCCC
John,
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
Europe.
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
this.
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
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.]
>>> 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
problems.
>>> 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,
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.
>>> 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”:
- 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 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,
John
_______________________________________________
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).
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).[attachment "CCSDS 431 DVB SCCC
pilot approaches.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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210421/4badb497/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 29166 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210421/4badb497/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 18937 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210421/4badb497/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 23443 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210421/4badb497/attachment-0005.gif>
More information about the SEA-SA
mailing list