[Sls-slp] [EXTERNAL] [BULK] Re: Addition of two NOTES to AOS 732.0-B pre-publication document with attachment

Fri Sep 19 04:03:38 EDT 2025

Eric,

Right - good catch.

Also we need to fix the following count of fields:

           *
General
The Transfer Frame Primary Header is mandatory and shall consist of five fields, positioned contiguously, in the following sequence:

  1.  Master Channel Identifier (12 bits; mandatory);
  2.  [Text Box: Issue 5] Virtual Channel Identifier (6 bits; mandatory);
  3.  Virtual Channel Frame Count (3 octets; mandatory);
  4.  Signaling Field (2 bits; mandatory);
  5.  Spacecraft ID MSB (2 bits; mandatory);
  6.  Virtual Channel Frame Count Cycle (4 bits; mandatory);
  7.  Frame Header Error Control (2 octets, optional).

It is seven fields now !!!

thanks,
Greg

From: Pitts, Eric L. (MSFC-HP27)[MOSSI2] <eric.l.pitts at nasa.gov>
Date: Friday, September 19, 2025 at 12:01 AM
To: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>, Matt Cosby <matt.cosby at goonhilly.org>, Leclerc Clement <Clement.Leclerc at cnes.fr>, sls-slp at mailman.ccsds.org <sls-slp at mailman.ccsds.org>
Subject: RE: [EXTERNAL] [BULK] Re: [Sls-slp] Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

I was reviewing the ISSUE 5 marked sections, and I have a question about the AOS Transfer Frame Primary Header.

Is the stated lengths of the Header accurate?  It is stated to be 6 to 8 octets but I added the fields and they were 6 octets and 2 bits minimum and 8 octets and 2 bits maximum.

12 + 6 + 24 + 2 + 2 + 4 = 50

[cid:image002.png at 01DC2909.0E0D9D50]

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> On Behalf Of Kazz, Greg (US 312B) via SLS-SLP
Sent: Thursday, September 18, 2025 9:18 AM
To: Matt Cosby <matt.cosby at goonhilly.org>; Leclerc Clement <Clement.Leclerc at cnes.fr>; sls-slp at mailman.ccsds.org
Subject: [EXTERNAL] [BULK] Re: [Sls-slp] Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

Agreed.

From: Matt Cosby <matt.cosby at goonhilly.org>
Date: Thursday, September 18, 2025 at 7:07 AM
To: Leclerc Clement <Clement.Leclerc at cnes.fr>, sls-slp at mailman.ccsds.org <sls-slp at mailman.ccsds.org>, Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>
Subject: [EXTERNAL] Re: Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **
PUBLIC

Hi Greg,

I spoke to Clement and he raised a good point that we should make sure that these discussions are captured. I suggested that we capture the AOS 8bit vs 10bit potential issues, as well as the AOS analysis in the updated green book. We just need to archive this data until we are ready to update the AOS green book.

Cheers, 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 Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Sent: Thursday, September 18, 2025 11:28
To: Leclerc Clement <Clement.Leclerc at cnes.fr>; sls-slp at mailman.ccsds.org <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

Hi Clement,

Thank you for your message.

I think some confusion is coming from Figure 4-2 Transfer Frame Primary Header. I will add a note in that figure that says, “Spacecraft ID MSB and LSB are not physically contiguous fields”.
For AOS Issue 4 and previous issues, TFVN was contiguous with the SCID. For AOS Issue 5, they are no longer contiguous.

I think that potential collisions could occur if implementations mix Issue 5 AOS transfer frames with Issue 4 or earlier AOS frames. In that case, we would have an incompatibility between the sizes of the V2 (AOS) frame. And if one side is looking only for an 8-bit AOS SCID but receives the 10-bit AOS SCID, it could be possible that a mistake is made in interpreting the SCID field. That is why we generated the note about when one evaluates the 2-bit MSB field (Issue 5) and when it is treated as spares (Issue 4 and previous).

Now, lets consider the hybrid case of sending AOS (TFVN = 2) and USLP (TFVN=4) frames. The first major difference is that in either AOS case, one would have either an 8-bit AOS SCID or a 10-bit AOS SCID (Issue 5 AOS book). USLP uses a 16-bit SCID. So, clearly, there is no collision possible there.

All TFVNs have been defined and are used by agency missions per below:
TFVN ’00’ TC or TM (Version 1)
TFVN ’01’ AOS (Version 2) - no more 8 bit SCIDs available -> must move to 10 bit SCIDs for future implementations
TFVN ‘10’ Prox-1 (Version 3)
TFVN  ’11’ USLP (Version 4)

MCID = TFVN + SCID

regards,
Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of Leclerc Clement via SLS-SLP <sls-slp at mailman.ccsds.org>
Date: Thursday, September 18, 2025 at 2:18 AM
To: sls-slp at mailman.ccsds.org <sls-slp at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [Sls-slp] Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

Hi Greg,

As I read the book and the modification, I'm concerned about the SCID collision possible with spacecraft using version 4.

In version 4 the  Master Channel Demultiplexing function had to verify MCID and discard if not incorrect.

The v4 MCI where the first 10 bits and now is a more complex construction of 12 bits. And the TFVN is the same in both version 0b10

The case I'm concerned about is the following :

Take a V4 SCID: SCID-A valued at 0b00 00 00 01 and a V5 SCID : SCID-B valued at 0b10 00 00 00 01.
If a V4 receiving end receives a V5 Frame il will read the MCID as 0b10 00 00 00 01

In this case the V4 Master Channel Demultiplexing function will pass the frame to the user. This may leads to error because the "true" MCID is 0b10 10 00 00 00 01

This could be easily corrected by changing the Version Frame number to 3 : 0b11 which seems a unused value yet and no other modification is foreseen in AOS as the group push to use USLP instead.

Do the group expect the receiving end using v4 to always check the reserved spare to be 0b00 not pass the frame is the reserved spare is different ? I don't find it specified anywhere in the Receiving End Procedure section.

Sorry for the late comment, so close to CMC poll.

Clément

________________________________
De : SLS-SLP <sls-slp-bounces at mailman.ccsds.org> de la part de Kazz, Greg (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org>
Envoyé : jeudi 18 septembre 2025 09:19:47
À : Kazz, Greg (US 312B) via SLS-SLP
Objet : [Sls-slp] Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

Dear SLP WG,

Attached please find the following updates to AOS SDLP (732.0) based upon the SLP WG review of the pre-publication copy.

The changes were made by the SLP WG during the meeting on Tuesday, Sept. 16, 2025 and are provided in the form of NOTES.

The first note already existed but needed to clarify that what used to be a spare field, must be set to ’00’ in the case that the SCID is used in version 4 or previous issues. NOT to leave it up to the user to “ignore” that field.
The second note warns the user that the B_PDU (bit service of AOS) does not have sufficient size to reach the end of data field, if larger size transfer frames are used (this is a consequence of increasing the FHP field for the M_PDU).

See these two changes highlighted in yellow below:

•                            4.1.2.5.4  Spacecraft Identifier (MSB)
1.                              Bits 42-43 of the Transfer Frame Primary Header shall contain the 2 mandatory most significant bits (MSB) of the Spacecraft ID.

NOTE   –    Missions implementing CCSDS 732.0-B (AOS) issue 4 or earlier set this field to ‘00’.

  *   4.1.4.3.3.4. If there are no valid user data in the Bitstream Data Zone (i.e., the B_PDU contains only idle data), the Bitstream Data Pointer shall be set to the value ‘all ones minus one’.

** NOTE – The Bit Stream Service User should be aware that the maximum transfer frame size is limited to 16384 bits due to the limitation of the B_PDU header Bit Stream Data Pointer. **

If there are no objections, I will pass these changes on to the Secretariat so that AOS SDLP (732.0) Issue 5 will be published as soon as possible.

best regards,
Greg
SLP WG Chair

The information contained in this message is intended for the addressee only and may contain classified or confidential information. If you are not the intended recipient, please delete this message and notify the sender; you must not copy, distribute, or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual and not necessarily those of the organisation. No reliance may be placed on this message without written confirmation from an authorised representative. No guarantee is implied that this message or any attachment is malware-free or has not been intercepted or amended. Under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018, any personal data contained in this email must be processed lawfully and fairly. If you have received this message in error, you must not retain or process the data and should notify the sender immediately. Goonhilly Earth Station Ltd is a company registered in England & Wales (No. 06896077). Registered office: Goonhilly Downs, Helston, Cornwall, TR12 6LQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250919/4a8a8705/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/20250919/4a8a8705/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 84818 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250919/4a8a8705/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img-58bf0bdb-983d-41c9-98ee-7a23707e854c
Type: application/octet-stream
Size: 923 bytes
Desc: img-58bf0bdb-983d-41c9-98ee-7a23707e854c
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250919/4a8a8705/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img-0bb44b0a-0eb5-42e8-adca-39146e825b9e
Type: application/octet-stream
Size: 270 bytes
Desc: img-0bb44b0a-0eb5-42e8-adca-39146e825b9e
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250919/4a8a8705/attachment-0003.obj>

[Sls-slp] [EXTERNAL] [BULK] Re: Addition of two NOTES to AOS 732.0-B pre-publication document ** with attachment **

[Sls-slp] [EXTERNAL] [BULK] Re: Addition of two NOTES to AOS 732.0-B pre-publication document with attachment