FW: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets

Kazz, Greg J greg.j.kazz at jpl.nasa.gov
Mon Mar 23 15:54:53 UTC 2009


For discussion at  the SLS-SLP WG meeting on Friday AM April 24 at Colorado Springs, CO

best regards,


From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Sunday, March 22, 2009 11:15 AM
To: Kazz, Greg J
Cc: Chris.Taylor at esa.int; Jean-Luc.Gerner at esa.int; Marjorie de Lande Long
Subject: ESA input for: [SLS-SLP] JAXA RIDs on AOS + TM Pink Sheets

        the following responses to Jaxa RIDs have been discussed with Chris and Marjorie.

Please consider these responses as ESA input for the discussion of the RIDs.


Gian Paolo


1) An Idle Packet carries no useful data: This applies to an Idle Space
Packet and to an Idle (or Fill) Encapsulation Packet (see below).
However, the AOS Insert Service uses the Insert Field of every Transfer
Frame on the Physical Channel, including the Idle Frames. Therefore, an
Idle Frame can carry useful data so the name "Idle Frame" is not fully
appropriate. The Pink Sheets provide the new name "OID Frame".
2) The term "OID Frame" is being introduced to AOS Space Data Link
Protocol for consistency with the existing term used for the TM Space
Data Link Protocol.  See section of CCSDS 132.0-B-1,
September 2003.
3) The term "Idle Frame" was first introduced for AOS by the publication
of the restructured Blue Book CCSDS 732.0-B-1 in September 2003: see
Table C-1.
4) There is a related editorial error in The Note 4 at the
end of contains a reference to [4] (Space Link IDs) which
should be [6] (Space Packet Protocol) for the specification of the Idle
5) The change to section mentions the "Fill Encapsulation
Packet". The Pink Sheets for the Encapsulation Service will change the
name to "Idle Encapsulation Packet".  Therefore, could also use
the new name.

Idle Packets
1) Idle Packet for Space Packet Protocol:  In 133.0-B-1, section says that the Secondary Header Flag must be 0 for Idle
Packets. And a note in says "The Packet Secondary Header is
not allowed for Idle Packets."
2) Idle (or Fill) Encapsulation Packet: The data area (Encapsulated Data
Field) contains idle data. The Encapsulation Packet Header has no
optional secondary fields for carrying extra data.

1) The RID says the descriptive phrase is unnecessary.  But the phrase
is in a Note, so there is no formal duplication. The phrase could help
the reader understand the meaning of "OID" and it provides a reference
to the location of the formal specification of the OID Frame.
2) It would be an improvement if the text was changed from "see 4.1.4"
to "see".

1) Section does not define the term "idle pattern". It uses
the term "idle pattern" in order to define the meaning of "Idle Data".
2) Apart from the "OID" name change, the new Note 3 is the only change
introduced to section  Note 3 does not alter the
specification of "Idle Data", but adds a suggestion that it should
have a random pattern, and it explains why.  This does not conflict
with the other details specified for the Idle Data, in or
elsewhere in 732.0-B.

1) The name change in TM and AOS protocols (132.0-B and 732.0-B) from
"Packet Service" to "Virtual Channel Packet Service" is consistent with
the "Virtual Channel Packet Service" of the TC protocol (232.0-B).  The
TM and AOS protocols do not use MAPs, so their renamed Virtual Channel
Packet Services place the packets into frames.
2) In 732.0-B (AOS), it might be helpful to remove GMAP ID, MAP ID, MAP,
MAPA and MAPP from the list of acronyms in Annex A, because they are not
used for the AOS protocol.
3) In 132.0-B (TM), it might be helpful to remove GMAP ID from the list
of acronyms in Annex A, because it is not used for the TM protocol.

The RID says it could be confusing to continue to use the term "Packet
Service" in AOS and TM protocols (there is a note about this at the end
of Table 2-1).  The intention of the Pink Sheets has been to replace all
instances of "Packet Service" in the text of 132.0-B and 732.0-B to
"Virtual Channel Packet Service" or "VCP Service".  However, there are
some Figures containing the words "Packet Service", and these have not
been changed. The note was added to Table 2-1 as explanation.
Therefore, it would be a good idea to ask the CCSDS Editor to replace
"Packet Service" with "VCP Service" in the Figures, and to remove the
note from Table 2-1. [This suggested change applies to 132.0-B and to


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090323/abfe25a7/attachment.html>

More information about the SLS-SLP mailing list