[Sls-slp] JAXA RID against OID Frame

Tue Mar 3 17:21:35 UTC 2009

G.P.,

But a Space Packet can contain a Secondary Header, which could contain useful data as well. So in that sense, OID Packet also makes sense. In other words, discarding an "Idle Packet" can have a drawback or unintended consequence. CCSDS needs to use consistent terminology across the board and I think that is what this JAXA rid is pointing out. I am looking forward to Marjorie's responses to those rids as well.

thanks,

Greg

________________________________
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Tuesday, March 03, 2009 1:26 AM
To: Kazz, Greg J
Cc: Greenberg, Edward; gilles.moury at cnes.fr; Jean-Luc.Gerner at esa.int; sls-slp at mailman.ccsds.org; sls-slp-bounces at mailman.ccsds.org; Takahiro Yamada
Subject: Re: [Sls-slp] JAXA RID against OID Frame

Greg,
        In Packet Telemetry the term "idle frame" was deprecated because it is posible that frame is not completely idle (opposite to the idle packet).
An idle frame can in fact contain a valid CLCW or a valid secondary header.
In such a sense:
1)  discarding an idle frame may imply loosing valid data while
2) discarding an idle packet has no drawback.

In CCSDS 732.0-B-2 I can read:
--------------------------------------------

4.1.2.3.2 The Virtual Channel Identifier shall be used to identify the Virtual Channel.
NOTES
...........
3 A Transfer Frame on the 'Idle' Virtual Channel may not contain any valid user data within its Transfer Frame Data Field, but it must contain the Insert Zone if the Insert Service is supported.
--------------------------------------------

4.1.4.1.5 In the case where at release time .....................
NOTES
1         Transfer Frames containing Idle Data in their Data Fields are sent to maintain synchronization at the receiver and also to transmit data in the Transfer Frame Insert Zone when there is no Data Field to send.
--------------------------------------------
Looking at Figure 4-1: AOS Transfer Frame Structural Components we see that an AOS frame may contain both an Insert Zone (equivalent to the Secondary header, I understand) and an Operational Control Field. Therefore the same reasoning of Packet TM do apply:
        An "idle frame" can contain (also) valid data (but not in the Data Field) while an Idle Packet does not contain any valid data
--------------------------------------------

Marjorie is preparing a coordinate ESA position with respect to all those RIDs.

Best regards

Gian Paolo

(*) Clearly for the CLCW - since the same CLCW is likely to be inserted in several frames - this would not happen if you have just one OID frame, but it could happen in a situation (that cannot be excluded a priori) where several OID frames are sent in sequence. In addition for the Secondary Header even a single frame could contain important data.

"Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov>
Sent by: sls-slp-bounces at mailman.ccsds.org

03-03-2009 01:23

To

"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>

cc

"Greenberg, Edward" <edward.greenberg at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, "Jean-Luc.Gerner at esa.int" <Jean-Luc.Gerner at esa.int>, Takahiro Yamada <tyamada at pub.isas.jaxa.jp>, "gilles.moury at cnes.fr" <gilles.moury at cnes.fr>

Subject

[Sls-slp] JAXA RID against OID Frame

G.P.

I think JAXA has a valid concern in the attached RID concerning the use of the term, OID, only idle data. I thought the purpose of using OID frame was to use the same terminology across all CCSDS space data link documents. But as pointed out in the rid, when we have an "Idle packet" it isn't called an OID packet, but rather and idle packet. So I am not sure that the term OID frame is consistent enough. Not that I am advocating the use of the term, OID packet at all. What do you think?
JAXA rid below.

thanks,

Greg

REVIEW ITEM DISPOSITION (RID):
                    RED BOOK RID INITIATION FORM

AGENCY RID NUMBER: JAXA-RPA830-01
SUBMITTING ORGANIZATION (Agency, Center): JAXA
------------------------------------------------------------------
REVIEWER'S NAME:   Shigeyuki Furushima
CODE:              Mitsubishi Electric Corporation
E-MAIL ADDRESS:    jaxa.ccsds at jaxa.jp
TELEPHONE:         29-868-2587
------------------------------------------------------------------
DOCUMENT NUMBER:   CCSDS 732.0-P-2.1        Pink Sheets, Issue 2.1
DOCUMENT NAME:     AOS Space Data Link Protocol
DATE ISSUED:       December 2008
PAGE NUMBER:                   PARAGRAPH NUMBER:
RID SHORT TITLE:  The cange from "Idle Frame" to "OID Frame" (1)
------------------------------------------------------------------
DESCRIPTION OF REQUESTED CHANGE:  (Use From: "..." To "..." format)

It's not necessary to change "Idele frame" to "OID Frame" .

The basis of suggestion is given below.

1. There is no change of definition in the recomendation.
   Changing word without changing definition will give rise to the confusion.

2. The purpose of this pink sheet is to clearfy the meaning of "idle."
   However, "Idle Packet" is not changed to "OID Packet."
   (See Page C-3, Table C-1)

------------------------------------------------------------------
CATEGORY OF REQUESTED CHANGE:
     Technical Fact ___    Recommended _X_    Editorial ___
NOTES:
TECHNICAL FACT:  Major technical change of sufficient magnitude as to
 render the Recommendation inaccurate and unacceptable if not
 corrected.  (Supporting analysis/rationale is essential.)
RECOMMENDED:  Change of a nature that would, if incorporated, produce
 a marked improvement in document quality and acceptance.
EDITORIAL:  Typographical or other factual error needing correction.
 (This type of change will be made without feedback to submitter.)
------------------------------------------------------------------
SUPPORTING ANALYSIS:

------------------------------------------------------------------
DISPOSITION:
 _______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sls-slp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090303/f5093fb6/attachment.html>