[SLS-CC] Fw: CCSDS 401 structure naming convention - proposed changes - list of received feedback

Andrea Modenini (external) Andrea.Modenini at esa.int
Fri Apr 16 07:21:06 UTC 2021


Dear all,
 please see email below from the RFM WG Chair, for which a discussion on 
the CCSDS 401 naming is proposed during the joint C&S and RFM meeting.


Regards


HE Space Operations for ESA - European Space Agency
Ph.D. Andrea Modenini
Communication Systems & Technologies Engineer 
TT&C and PDT Systems & Techniques Section (TEC-EST)
RF Systems Division
ESTEC
Keplerlaan 1, PO Box 299
NL-2200 AG Noordwijk, The Netherlands
andrea.modenini at esa.int | www.esa.int
T +31 71 56 53439
----- Forwarded by Andrea Modenini/estec/ESA on 16-04-21 09:18 -----

From:   Enrico Vassallo/esoc/ESA
To:     sls-rfm at mailman.ccsds.org
Cc:     Andrea Modenini/estec/ESA at ESA, "Andrews, Kenneth S (JPL-332B)[Jet 
Propulsion Laboratory]" <kenneth.s.andrews at jpl.nasa.gov>
Date:   16-04-21 09:03
Subject:        CCSDS 401 structure naming convention - proposed changes - 
list of received feedback


Dear All,

I have received a number of proposals, not all aligned .... Basically, we 
now have many more possibilities than I had thought of:

1.      Change the title of section 2.2 to something like "Telecommand and 
forward data" and that of section 2.4 to something like "Telemetry and 
return data" 
        Pro: Easy title 
        Con:  Would need to check in detail all recommendations in 2.2 and 
2.4, which may require a considerable effort

2a      Change the section titles to "Telecommand (including data 
transfer)" and "Telemetry (including data transfer)" 
        Pro:  Avoid checking current recommendations for consistency
        Con: Meaning/interpretation may not be understood/clear

2b      As 2a but using as alternative to "data transfer" the "payload" 
word 
        Pro:  Avoid checking current recommendations for consistency
        Con: Payload is not generally utilized to indicate the same thing 
in different fora

3a      Ignore this semantic problem and leave everything unchanged
        Pro: no effort
        Con: May cause confusion/does not address the concern

3b      Address semantic problems with dedicated notes in section 2.0 
concerning sections  2.2 and 2.4,  and leave everything else unchanged
        Pro: minimal effort 
        Con: none identified

4.      Change the title of Section 2.2 to "Forward" and that of 2.4 to 
"Return" by itself or whatever other word is needed such as "data, link, 
etc."
        Pro: as option 1
        Con: as option 1 and depending on exact text also as option 2a/2b

Given that this terminology is also used in C&S WG books, it is proposed 
that discussion be continued at the upcoming joint RFM/C&S WG meeting.

Thanks to all respondents and to Shannon for providing most pros and cons.

Regards, Enrico

----- Forwarded by Enrico Vassallo/esoc/ESA on 15/04/21 14:32 -----

From:   Gian Paolo Calzolari/esoc/ESA
To:     Enrico Vassallo/esoc/ESA at ESA
Cc:     "Jon Hamkins" <Jon.Hamkins at jpl.caltech.edu>, "Rodriguez, Shannon 
(GSFC-5670)" <shannon.rodriguez-1 at nasa.gov>, "Sank, Victor J. 
(GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" 
<victor.j.sank at nasa.gov>, "Fong, Wai H. (GSFC-5670)" 
<wai.h.fong at nasa.gov>, "Lee, Wing-tsz (GSFC-5670)" 
<wing-tsz.lee-1 at nasa.gov>
Date:   10/04/21 11:50
Subject:        Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes


Enrico,
Shannon,
        it looks as Option 3 by Shannon could be reworded as follows 
showing then a couple of sub options 

3.        Leave titles unchanged and
3.         Leave titles unchanged, and
        3a        Ignore semantic problem and leave everything unchanged
        3b        Address semantic problems with dedicated notes.

consider also that - in my quality of Area Director - I comment on this 
issues with a critical spirit trying to highlight points to be considered 
(as e.g. side effects) to take the best decision but, as usual, I will 
stay and support the WG choice.

Regards

Gian Paolo





From:   Enrico Vassallo/esoc/ESA
To:     "Rodriguez, Shannon (GSFC-5670)" <shannon.rodriguez-1 at nasa.gov>
Cc:     Gian Paolo Calzolari/esoc/ESA at ESA, "Jon Hamkins" 
<Jon.Hamkins at jpl.caltech.edu>, "Sank, Victor J. (GSFC-567.0)[SCIENCE 
SYSTEMS AND APPLICATIONS INC]" <victor.j.sank at nasa.gov>, "Fong, Wai H. 
(GSFC-5670)" <wai.h.fong at nasa.gov>, "Lee, Wing-tsz (GSFC-5670)" 
<wing-tsz.lee-1 at nasa.gov>
Date:   10-04-21 11:37
Subject:        Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes



Hi Shannon.

Feel free to copy the whole WG for transparency.
I think that Jon and Gian Paolo proposed another option or a subset of 3 
with the addition of explanatory notes.
Given the recommendation by Jon to involve C&S, I think we will have to 
discuss it at the next videoconf.

I will wait until the deadline to finalize the list of proposals.

Nice week-end,

Enrico

On Apr 9, 2021, at 20:59, Rodriguez, Shannon (GSFC-5670) 
<shannon.rodriguez-1 at nasa.gov> wrote:

 
Hello  Enrico,
 
(Note that I removed the listserv and only cc’d the ones that had replied 
and GSFC people)
 
I see 4 options (1 added per email trail) summarized again below. From 
these, if we are voting online, I would go with the ones with the word 
Forward/return in it (options 1 or 4)
 
1.      Change the title of section 2.2 to something like "Telecommand and 
forward data" and that of section 2.4 to something like "Telemetry and 
return data". 
Pro: Easy title 
Con:  Would need to check in detail all recommendations in 2.2 and 2.4, 
which is a lot of work I think. 
2.      Change the section titles to "Telecommand (including data 
transfer)" and "Telemetry (including data transfer)" 
Pro:  avoid checking current recommendations for consistency. 
Con: Meaning/interpretation
2a)  Or, could use as alternative to "data transfer" the "payload" word 
although this is not generally utilized to indicate the same thing in 
different fora. 
3.        Ignore this semantic problem and leave everything unchanged.
​
4.      Change the title of Section 2.2 to “Forward, and 2.4 to “Return” 
by itself or whatever other word is needed such as “data, link, etc.”
 
 
Thanks,
Shannon
 
From: SLS-RFM <sls-rfm-bounces at mailman.ccsds.org> on behalf of Jon Hamkins 
via SLS-RFM <sls-rfm at mailman.ccsds.org>
Reply-To: Jon Hamkins <Jon.Hamkins at jpl.caltech.edu>
Date: Thursday, April 8, 2021 at 4:59 PM
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, Victor 
Sank <victor.j.sank at nasa.gov>
Cc: "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org>
Subject: Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes
 
I think of "telemetry" as a generic term which does not necessarily imply 
the type of data or its direction (but it could, based on context or 
historical convention). For example, in the optical coding standard the 
title "HPE telemetry signaling" is used for a section describing  one type 
of optical code+modulation. The data can be anything as long as it is put 
in Transfer Frames, and the direction can be forward or return.
     ----Jon
Jon Hamkins
Chief Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 (preferred)   |   M 626-658-6220 (does not work at home)

JPL   |   jpl.nasa.gov 
On 4/8/2021 1:15 PM, Gian.Paolo.Calzolari at esa.int wrote:
Again, 
        why should a modulation care whether the bits are from a USLP 
Frame or something else? 

I find true the reverse, who is deciding between TM/AOS/USLP Frames may do 
a choice or another depending on the technology available. 

As well, considering your correct statement "An Earth based receiver can 
be much more complicated than a space based receiver." it is also true 
that if you simply call that link a return link the receiver could also be 
in space. Then are you really simplifying the matter? 

About name changes, I keep my preference for NOTES inserted where needed 
with more efficiency and less effort with respect to the side effect to 
checked within the document and outside the document (e..g people used to 
some terminology getting confused, references screwed up etc etc) 

My cent 

Gian Paolo 



From:        "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND 
APPLICATIONS INC]" <victor.j.sank at nasa.gov> 
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> 
Cc:        "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org> 
Date:        08-04-21 20:45 
Subject:        RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes 

 
Gian Paolo, 
              As much as I like details, I agree that the title need not 
say what the data is.  But it would be good to change the term “Command” 
and “Telemetry”. 
              A big part of the intent of USLP is to make the “forward” 
link and “return” link as similar as possible.  But we may still want to 
treat them with some differentiation.  An Earth based receiver can be much 
more complicated than a space based receiver.   An Earth based transmitter 
can have much more EIRP than a space based one. The section titles can be 
simple but if possible, it would be nice if they informed the reader of 
the differences.  It may be as simple as words like “forward” and “return” 
to indicate the initiator and the respondent, and let the section contents 
cover the details. 
Thanks,
Victor
 
From: Gian.Paolo.Calzolari at esa.int <Gian.Paolo.Calzolari at esa.int> 
Sent: Thursday, April 8, 2021 2:14 PM
To: Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] 
<victor.j.sank at nasa.gov>
Cc: Enrico.Vassallo at esa.int; Jon Hamkins <Jon.Hamkins at jpl.caltech.edu>; 
sls-rfm at mailman.ccsds.org
Subject: RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes
 
Victor, 
       my basic question with respect to a specific aspect of this 
discussion  is the following: does RFM WG really need to enter into the 
detail of the type of carried data? 
I mean, the input to a modulator is normally a stream of encoded bits. Why 
would RFM need to know if those bits are from Housekeeping Telemetry or 
from a scientific payload or from both? 
The same for telecommand: does the modulator care about knowing the data 
contain a command or a memory upload? 

All this acknowledging that other points of the discussion may require 
further discussion by the WG. 

Ciao 

Gian Paolo 



From:        "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND 
APPLICATIONS INC]" <victor.j.sank at nasa.gov> 
To:        "Jon Hamkins" <Jon.Hamkins at jpl.caltech.edu>, "
Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, "
Enrico.Vassallo at esa.int" <Enrico.Vassallo at esa.int> 
Cc:        "sls-rfm at mailman.ccsds.org" <sls-rfm at mailman.ccsds.org> 
Date:        08-04-21 20:04 
Subject:        RE: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes 

 
Dear Enrico,
              Before jumping into the section titles, I think we need to 
agree on the meaning of the basic terms.
              It seems to me that the term “command” is a limited term and 
should be improved.  Saying “uplink” is no longer good enough since we 
must cover cross links.  The term “Forward Link” has value because it can 
cover many cases and to me implies the sender, no matter if it is an “up” 
or “down” link.  It does not cover what kind of data is being sent.
              A remaining part of the terminology question is whether we 
want to term to cover the type of data or information that is being 
conveyed.  The term “command” is very specific, it is a command and not 
science data or a software load.  But the term “telemetry” seems to be 
less specific.  I generally think of it as the return of housekeeping and 
engineering information but I believe the term is used very general to 
also include the returned (down linked) science or operational data.  We 
need to define what we mean by “telemetry”.  My vote would be to use that 
term “telemetry” for the housekeeping and engineering data on the return 
link.  On some projects we refer to the other returned data as the 
“operational” data for a space weather satellite and “science” data for a 
purely science satellite.  I do not have a strong opinion, just stating 
terms I have seen in use. 
 
The section titles
              Seems to me that section 2.2 Command and 2.4 Telemetry, 
titles need to be improved. 
I hesitate to propose the possible rewording until we decide on the 
definition of the terms and if we what the title to convey of the kind of 
data transferred.  I think the title should contain some detail but at the 
same time be general enough to allow for things we have not thought of, if 
such thing is possible. 
 
Regards,
Victor
 
From: SLS-RFM <sls-rfm-bounces at mailman.ccsds.org> On Behalf Of Jon Hamkins 
via SLS-RFM
Sent: Thursday, April 8, 2021 11:20 AM
To: Gian.Paolo.Calzolari at esa.int; Enrico.Vassallo at esa.int
Cc: sls-rfm at mailman.ccsds.org
Subject: Re: [Sls-rfm] [EXTERNAL] Re: CCSDS 401 structure naming 
convention - proposed changes
 

I think the note is a good idea to explain the more general nature of 
these transmissions. If a change in terminology is made, I suggest 
coordination with C&S and OPT Working Groups, because their blue books are 
also using the terms telemetry and/or telecommand. 
    ----Jon 
Jon Hamkins
Chief Technologist, Communications, Tracking, and Radar Division
O 818-354-4764 (preferred)   |   M 626-658-6220 (does not work at home)

JPL   |   jpl.nasa.gov 
On 4/8/2021 3:21 AM, Gian.Paolo.Calzolari at esa.int wrote:
Dear Enrico, 
      frankly speaking, the third possibility look to me the best one. 
If strongly needed, a note could be added about using historical titles. 

The general problem is that using new/different terms - as you correctly 
remarks - 401.0-B may enter in conflict with different fora including 
usage within CCSDS. 

As an example, the notation forward/return (link) is mainly used to 
generalise the diction specially when one side in not on Earth as done in 
Proximity-1 Physical Layer book (see 
https://public.ccsds.org/Pubs/211x1b4e1.pdf ) 

Ciao 

Gian Paolo 





From:        Enrico.Vassallo at esa.int 
To:        sls-rfm at mailman.ccsds.org 
Date:        08-04-21 10:05 
Subject:        [Sls-rfm] CCSDS 401 structure naming convention - proposed 
changes 
Sent by:        "SLS-RFM" <sls-rfm-bounces at mailman.ccsds.org> 




Dear RFM WG colleagues, 

discussing high rate 22 GHz uplink recommendations, we noted that the 
current structure naming convention may not be appropriate to cover 
"generic" data transfer applications: 
      2.1        Earth-to-Space Radio Frequency                2.4 
Telemetry 
     2.2        Telecommand                                        2.5  
Radio Metric 
     2.3        Space-to-Earth Radio Frequency                2.6 
Spacecraft 

One possible solution would be to change the title of section 2.2 to 
something like "Telecommand and forward data" and that of section 2.4 to 
something like "Telemetry and return data". 

This is to distinguish between telecommand and uplink data transfers (like 
on-board software patch uploading, etc.) and between (HK) telemetry and 
payload transmissions. 
Note that already now recs 2.4.8 and 2.4.23 do not mention telemetry in 
the title and deal with payload data. However, both recommendations have 
pictures for symbol rate definition with captions indicating telemetry 
symbol rate. I assume we will have the same in section 2.2. 
One would need to check in detail all recommendations in 2.2 and 2.4, 
which is a lot of work I think. 

Another possibility is to change the section titles to "Telecommand 
(including data transfer)" and "Telemetry (including data transfer)" so 
that we can avoid checking current recommendations for consistency. 

In addition, one could use as alternative to "data transfer" the "payload" 
word although this is not generally utilized to indicate the same thing in 
different fora. 

The third possibility is to ignore this semantic problem and leave 
everything unchanged. 

Could I have your view  by April 15 COB? 



Regards, Enrico 


 





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/sls-cc/attachments/20210416/c934d9b4/attachment-0001.htm>


More information about the SLS-CC mailing list