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

[Kazz, Greg (US 312B)]

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)
                 *
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20250918/4b18e106/attachment-0001.htm>