[SLS-CC] Fw: CCSDS 732 section 4.1.2.6 Header Error Control

Mon Sep 20 15:59:19 UTC 2021

Dear Andrea, 

All the reasons identified by Victor's e-mail below, provide a fair 
rational for deletion of the Frame Header Error Control field from the AOS 
Standard, except the misuse, which cannot be charged on AOS's bill. 
The additional overhead it's also of a lesser concern, since it s only 
around 0.1%.
In any case, we have currently several missions in EU that use the AOS 
including FHEC field, and more are in the pipeline (e.g. the six 
Copernicus Expansion Missions) with the same frame format configuration. 
Therefore, as a first reaction, I would not be in favour of removing the 
FHEC field from the AOS book, since by doing this we would make the new 
missions non-compliant. 
Moreover, the FHEC field is optional, each mission who does not need it, 
can opt-out. In this respect, the standard is already providing sufficient 
flexibility. 
So, all in all, while I see some advantages in removing the FHEC I also 
see an equal amount of benefits leaving it in the book. 

Nevertheless, I will survey internally, both on-board and on-ground teams 
in ESA to gather an Agency's view averaged across different departments. 
I'll let you know soon. 

In any case, message to SLS-SLP, even if the final decision were to remove 
it, I would do it "gracefully". 
We could in principle find a way to indicate kind of "not recommended for 
new design" clause/note in the next version of 732.0 book and in 5 or 10 
years (i.e. one or two review cycles) we will eventually remove it. 

Cheers
Marco 

From:   Andrea.Modenini at esa.int
To:     "Space Link Coding & Synchronization Working Group" 
<sls-cc at mailman.ccsds.org>
Cc:     "Greg Kazz" <Greg.J.Kazz at jpl.nasa.gov>, "Matthew Cosby" 
<Matt.Cosby at Goonhilly.org>
Date:   17/09/2021 11:41
Subject:        [SLS-CC] Fw: CCSDS 732 section 4.1.2.6 Header Error 
Control
Sent by:        "SLS-CC" <sls-cc-bounces at mailman.ccsds.org>

Dear all, 
 JPL and GSFC brought to my attention that CCSDS 732, Section 4.1.2.6, 
specifies a shortened RS code that was originally meant for uncoded or 
convolutional only coded telemetry links. 

However (see Victor's email below) it was found that this specification 
was often misused, just becoming an additional overhead for the link. 
Additionally, the specification itself appears incomplete, leaving 
ambiguities to its actual implementation. 
For this reason, JPL and GSFC are proposing to eliminate it. 

Could you please pool your Agencies, and let me know your position no 
later than 1st October 2021? 
So that C&S WG can then formalise its position to SLP before next Fall 
Meeting. 

Kind Regards 

ESA - European Space Agency 
Ph.D. Andrea Modenini
TT&C Communications Systems 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, M +31 6 484 56 527 
----- Forwarded by Andrea Modenini/estec/ESA on 17-09-21 10:35 ----- 

From:        "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND 
APPLICATIONS INC]" <victor.j.sank at nasa.gov> 
To:        "Andrea.Modenini at esa.int" <Andrea.Modenini at esa.int> 
Cc:        "Rodriguez, Shannon (GSFC-5670)" 
<shannon.rodriguez-1 at nasa.gov>, "Kazz, Greg J (JPL-312B)[JPL Employee]" 
<greg.j.kazz at jpl.nasa.gov>, "Fong, Wai H. (GSFC-5670)" 
<wai.h.fong at nasa.gov>, "Andrews, Kenneth S (JPL-332B)[JPL Employee]" 
<kenneth.s.andrews at jpl.nasa.gov>, "Hamkins, Jon (JPL-3300)[JPL Employee]" 
<jon.hamkins at jpl.nasa.gov> 
Date:        15-09-21 21:09 
Subject:        CCSDS 732 section 4.1.2.6 Header Error Control 

Andrea,
              There is a shortened 15,11  RS code (q = 1 so shortened to 
14,10) in the CCSDS 732.0-B-3 book section 4.1.2.6 that is specified for 
use in the transfer frame header that we believe is a hang over from the 
days before the popular use of RS or other more powerful block codes that 
get applied to the entire transfer frame.  It is intended for the case of 
convolution only code or the case of no error correction code.  We have 
had a few missions miss use this code and were wondering if CCSDS should 
remove it from the 732 book.  You can see from the email from Greg below 
that JPL has no missions that use this code and over the last 
approximately 20 years, GSFC is only aware of it being used where it was 
not intended.  It is also odd that this code is only specified in the 732 
book and not the 131 books. 
              Being a shortened code, I find the specification incomplete. 
 As a shortened code it is necessary to specify where the virtual fill 
should go, at the beginning or at the end (or else ware).  In addition, it 
is not specified what value the virtual fill nibble (4 bits) should be. 
Most common would be all zeros, but it needs to be specified.  Without 
these additional details, a ground station receiver vendor would have to 
make these parameters user selectable.  The protection leaves out the VCID 
count, it only covers the MCID, VCID and Signaling Field.  Seems to me an 
error in the VCID counter can make the frame useless.   Using this header 
code makes the primary header 8 bytes long which I do not think is 
specified any where else. 
              Your thoughts please and if you agree, can you ask each C&S 
WG member to poll their respective agency so at the next meeting we can 
discuss the possibility of eliminating it from the 732.0 blue book? 
Thanks,
Victor

From: Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov> 
Sent: Tuesday, September 14, 2021 11:41 AM
To: Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <
victor.j.sank at nasa.gov>
Subject: Re: [EXTERNAL] Re: Minor wording in CCSDS 732 section 4.1.2.6 
Header Error Control

Victor,

At least at JPL, no mission uses the AOS transfer frame header error 
control. It would be worthwhile if you ask Andrea that each C&S WG member 
poll their respective agency to see if at the next meeting we could see if 
it could be eliminated from the 732.0 blue book. 

Greg

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-CC mailing list
SLS-CC at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc

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/20210920/b990f248/attachment.htm>