<span style=" font-size:10pt;font-family:sans-serif">Dear Andrea, </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">The additional
overhead it's also of a lesser concern, since it s only around 0.1%.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">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.
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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.
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">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. </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Nevertheless,
I will survey internally, both on-board and on-ground teams in ESA to gather
an Agency's view averaged across different departments. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">I'll let you know
soon. </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">In any case, message
to SLS-SLP, even if the final decision were to remove it, I would do it
"gracefully". </span>
<br><span style=" font-size:10pt;font-family:sans-serif">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. </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Cheers</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Marco </span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif"> </span>
<br>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">Andrea.Modenini@esa.int</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Space
Link Coding & Synchronization Working Group" <sls-cc@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Greg
Kazz" <Greg.J.Kazz@jpl.nasa.gov>, "Matthew Cosby"
<Matt.Cosby@Goonhilly.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">17/09/2021
11:41</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[SLS-CC]
Fw: CCSDS 732 section 4.1.2.6 Header Error Control</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SLS-CC"
<sls-cc-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Dear all,</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
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.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
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.</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
For this reason, JPL and GSFC are proposing to eliminate it.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Could you please pool your Agencies, and let me know your position <u>no
later than 1st October 2021</u>? <br>
So that C&S WG can then formalise its position to SLP before next Fall
Meeting.</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
</span><span style=" font-size:12pt"> <br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Kind Regards</span><span style=" font-size:12pt"> <br>
<br>
</span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b><br>
ESA - European Space Agency</b></span><span style=" font-size:12pt"> </span><span style=" font-size:8pt;color:#00a1e0;font-family:Verdana"><b><br>
Ph.D. Andrea Modenini</b></span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><b><br>
TT&C Communications Systems Engineer</b></span><span style=" font-size:12pt"><b>
</b></span><span style=" font-size:8pt;color:#808080;font-family:Verdana"><br>
TT&C and PDT Systems & Techniques Section (TEC-EST)<br>
RF Systems Division<b><br>
ESTEC</b><br>
Keplerlaan 1, PO Box 299<br>
NL-2200 AG Noordwijk, The Netherlands<br>
andrea.modenini@esa.int | </span><a href=http://www.esa.int/><span style=" font-size:8pt;color:#8f8f8f;font-family:Verdana"><u>www.esa.int</u></span></a><span style=" font-size:8pt;color:#808080;font-family:Verdana"><br>
T +31 71 56 53439, M +31 6 484 56 527</span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#800080;font-family:sans-serif"><br>
----- Forwarded by Andrea Modenini/estec/ESA on 17-09-21 10:35 -----</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
From: </span><span style=" font-size:9pt;font-family:sans-serif">"Sank,
Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" <victor.j.sank@nasa.gov></span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
To: </span><span style=" font-size:9pt;font-family:sans-serif">"Andrea.Modenini@esa.int"
<Andrea.Modenini@esa.int></span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Cc: </span><span style=" font-size:9pt;font-family:sans-serif">"Rodriguez,
Shannon (GSFC-5670)" <shannon.rodriguez-1@nasa.gov>, "Kazz,
Greg J (JPL-312B)[JPL Employee]" <greg.j.kazz@jpl.nasa.gov>,
"Fong, Wai H. (GSFC-5670)" <wai.h.fong@nasa.gov>, "Andrews,
Kenneth S (JPL-332B)[JPL Employee]" <kenneth.s.andrews@jpl.nasa.gov>,
"Hamkins, Jon (JPL-3300)[JPL Employee]" <jon.hamkins@jpl.nasa.gov></span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Date: </span><span style=" font-size:9pt;font-family:sans-serif">15-09-21
21:09</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Subject: </span><span style=" font-size:9pt;font-family:sans-serif">CCSDS
732 section 4.1.2.6 Header Error Control</span><span style=" font-size:12pt">
<br>
</span>
<hr noshade><span style=" font-size:12pt"><br>
</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Andrea,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
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.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">
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? </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Thanks,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Victor</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
Kazz, Greg J (US 312B) <</span><a href=mailto:greg.j.kazz@jpl.nasa.gov><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>greg.j.kazz@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<b><br>
Sent:</b> Tuesday, September 14, 2021 11:41 AM<b><br>
To:</b> Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]
<</span><a href=mailto:victor.j.sank@nasa.gov><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>victor.j.sank@nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">><b><br>
Subject:</b> Re: [EXTERNAL] Re: Minor wording in CCSDS 732 section 4.1.2.6
Header Error Control</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Victor,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">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. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Greg</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<br><tt><span style=" font-size:12pt">This message is intended only for
the recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).<br>
</span></tt>
<br><tt><span style=" font-size:10pt">_______________________________________________<br>
SLS-CC mailing list<br>
SLS-CC@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-cc</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt>
<br>
<br><PRE>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@esa.int).
</PRE>