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

Mon Sep 20 17:53:12 UTC 2021

The graceful deprecation is a promising idea. In addition to adding the 
"not recommended for new design" clause, it would be helpful to specify 
the value and position of the virtual fill, which could be set to match 
what the EU missions are currently doing. I assume it is the same as the 
method in the 131.0-B-3 book (all zeroes, at the beginning of the 
codeword), but it would be good to clarify.

      ----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 9/20/2021 8:59 AM, Marco.Rovatti at esa.int wrote:
> 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_ 
> <https://urldefense.us/v3/__http://www.esa.int/__;!!PvBDto6Hs4WbVuu7!bNqPG5_9INpete3Q1dj8WlabQwEnJTyFyg0Pe_YmsV5NkjzssPr878pouZTp6dgrsRJFoHQ$>
> 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_ 
> <mailto: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_ <mailto: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 
> <https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!bNqPG5_9INpete3Q1dj8WlabQwEnJTyFyg0Pe_YmsV5NkjzssPr878pouZTp6dgrhyF-e-g$>
>
>
> 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://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc__;!!PvBDto6Hs4WbVuu7!bNqPG5_9INpete3Q1dj8WlabQwEnJTyFyg0Pe_YmsV5NkjzssPr878pouZTp6dgrhyF-e-g$  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-cc/attachments/20210920/9f810f04/attachment-0001.htm>