[Sls-slp] RID resolution to AOS Space Data Link Protocol (SDLP) 732.0-B

[Matt Cosby]

Hi Marco,

Greg and I have just had the same conversation. We agree that the changes should not impact “legacy systems”, as the 5 bits will be set to zero for frames that legacy systems are able to support.

I also think that a note is not required, as legacy systems will be compatible with the pink sheets as they will only be able to support the smaller frame sizes – which means the smaller FHPs

Thanks, Matt.


Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd

[signature_1318327456]

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> On Behalf Of Marco Rovatti via SLS-SLP
Sent: Tuesday, November 7, 2023 11:27 AM
To: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>; sls-slp at mailman.ccsds.org
Subject: Re: [Sls-slp] RID resolution to AOS Space Data Link Protocol (SDLP) 732.0-B

Dear Greg, all,

First of all, my apologies for not having been able to join the Fall Meeting, unfortunately I am in Bremen working for Copernicus Expansion missions.

Perhaps the way I see this is a bit naïve, however, the need for using a longer FHP is driven by the selected C&S standard.
New missions planning to use AOS 4.1 over DVB-2 or ACM and wanting to benefit from legacy HW/SW would need to restrain the max length of Transfer Frame to 2048 bytes at mission level.
In this way, the legacy unit’s “non-compliance” would have no practical consequences. Even an AOS4.1 compliant transmitter would never generate a FHP “longer than 11 bit”, meaning the most significant bits of the FHP will be set to zeroes  as a consequence of the shorter Transfer Frame length.

Maybe, instead of keeping the old text, either as an optional requirement or as a note, we can just put a note in the blue book to highlight this constraint in case a mix of legacy equipment and new standards are used.

What do you think?

Best regards
Marco

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> On Behalf Of Kazz, Greg (US 312B) via SLS-SLP
Sent: Tuesday, November 7, 2023 10:37 AM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] RID resolution to AOS Space Data Link Protocol (SDLP) 732.0-B

Dear SLP WG,

I believe I sent out this provisional RID disposition to the SLP WG already, but since it the AOS SDLP pink sheet review is not over until Dec 11, I would like to see if we can come to consensus on the RID disposition at this Fall meeting.

I had planned to walk through it yesterday, but it seems to have fallen off the agenda.
Nevertheless, I do believe the solution is rather straightforward.

The RID comes from ESA (Andrea Modenini).
The subject is the expansion of the First Header Pointer in AOS SDLP from 11 bits to 16 bits, using the current 5 spare bits in the M_PDU header so that AOS can accommodate up to the maximum size transfer frames as USLP does, i.e., 64K frames.
The RID focuses on how CCSDS should reconcile legacy missions use with new mission use of this expanded field.

Attached as word document (which I have placed into the CWE)  is my provisional response to Andrea subject to your comments. Andrea has written me back and agrees that a NOTE is better than changing the normative text.

Please let me know if you have any concerns or issue with this resolution. Depending upon your replies, we will carry on by email. By 12/11/2023, we will see if any additional RIDs arrive and then we will need to disposition them by email as well.

Best regards,
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<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20231107/e9ce5ddb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 16125 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20231107/e9ce5ddb/attachment-0001.jpg>