[Sls-rfm] CCSDS 401 structure naming convention - proposed changes

[Gian.Paolo.Calzolari at esa.int]

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).
_______________________________________________
SLS-RFM mailing list
SLS-RFM at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-rfm



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-rfm/attachments/20210408/ea62bd4d/attachment.htm>