[Sls-slp] JAXA RID against OID Frame

Marjorie de Lande Long marjorie at delandelong.com
Thu Mar 5 08:54:04 UTC 2009


Greg and everyone,

> the way the standard is written today, it is possible for a project to
> think that they could put data into a packet secondary header of an
> OID packet and think it is a valid thing to do.

An Idle Packet for the Space Packet Protocol really is Idle.  It is not
permitted to have a Packet Secondary Header.  The standard (133.0-B-1,
September 2003) is clear on this point.  Section 4.1.2.3.3.4 says
"The Secondary Header Flag shall be set to '0' for Idle Packets." 
and a Note in 4.1.3.2.1.4 says 
"The Packet Secondary Header is not allowed for Idle Packets."  

This requirement was inherited from the old Blue Books (now Silver).
For example, 102.0-B-5 ("Packet Telemetry") says in section 3.1.2.2.d
"The Packet Secondary Header Flag shall be set to "0" for Idle Packets."

Best regards,
Marjorie

On Wed, 2009-03-04 at 16:34 -0800, Kazz, Greg J wrote:
> Ed,
> 
>  
> 
> You are saying the service provider (DSN, SN, GN, ESA, etc) would not
> provide OID packets to the user. I agree. I was only saying that the
> way the standard is written today, it is possible for a project to
> think that they could put data into a packet secondary header of an
> OID packet and think it is a valid thing to do.
> 
>  
> 
> Greg
> 
>  
> 
>                                    
> ______________________________________________________________________
> From: Greenberg, Edward 
> Sent: Wednesday, March 04, 2009 4:18 PM
> To: Kazz, Greg J; Matt Cosby; Gian.Paolo.Calzolari at esa.int
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY;
> Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org;
> gilles.moury at cnes.fr
> Subject: Re: [Sls-slp] JAXA RID against OID Frame
> 
> 
>  
> 
> NO,  Projects should not be allowed to get fill/idle/OID packets.
>      OID frames on the other hand can contain insert data if managed
> for the physical channel (TM or AOS)
> 
> 
> On 3/4/09 8:26 AM, "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote:
> 
> You are all thinking very logically. But flight projects often cut
> corners and find all sorts of unusual and esoteric ways of utilizing
> the standards. Consensus on this matter seems to be, yes it is
> possible, but the limit of the probability of doing so approaches
> zero.
>  
> Greg
>  
> 
>                                    
> ______________________________________________________________________
> From: Greenberg, Edward 
> Sent: Wednesday, March 04, 2009 3:03 AM
> To: Matt Cosby; Gian.Paolo.Calzolari at esa.int; Kazz, Greg J
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Tim RAY;
> Jean-Luc.Gerner at esa.int; sls-slp-bounces at mailman.ccsds.org;
> gilles.moury at cnes.fr
> Subject: Re: [Sls-slp] JAXA RID against OID Frame
> 
> I agree with Matt and Gian Paolo.  If you want to send a packet with a
> meaningful secondary header and no useful information thengive it an
> APID with that interpretation, not one that says it only contains idle
> data.    Have a wonderful time discussing this trivia.  
> 
> 
> On 3/4/09 1:59 AM, "Cosby Matthew" <MCOSBY at qinetiq.com> wrote:
> Greg,
>  
> I agree with Gian Paolo. 
>  
> When our TM systems detect an Idle Packet (APID set to 0x7FF) it
> discards it. 
>  
> >From the TM Spec.
> 4.3.2.5 Extracted Packets shall be delivered to the users on the basis
> of the PVN in their header. Incomplete Packets are not required to be
> delivered in cross support situations. 
> 
> NOTE . Idle Packets are discarded. Data Fields that contain only Idle
> Data are also discarded.
> 
> This states that the Idle Packet is discarded and implies that there
> is no user data within the packet. There probability isn’t any where
> in the standard stating that you can’t put a secondary header in the
> Idle Packet, but this is implied as this packet is thrown out. So
> quoting Gian Paolo it would be crazy to put any useful data into the
> idle packet.
>  
> Regards,
>  
> Matt.
> 
> Matthew Cosby
> 
> QinetiQ
> Bldg X107 Rm G003
> Cody Technology Park
> Ively Road, Farnborough
> Hants, GU14 0LX
> 
>   Tel:  01252 396313  
>   Email:  mcosby at QinetiQ.com  
>   Fax:  01252 392969  
>   Web:  www.QinetiQ.com <http://www.qinetiq.com>    
> QinetiQ - The Global Defence and Security Experts 
> 
> P Please consider the environment before printing this email. 
> 
>                                    
> ______________________________________________________________________
> From: sls-slp-bounces at mailman.ccsds.org
> [mailto:sls-slp-bounces at mailman.ccsds.org]
> <mailto:sls-slp-bounces at mailman.ccsds.org%5d> On Behalf Of
> Gian.Paolo.Calzolari at esa.int
> Sent: 03 March 2009 18:21
> To: Kazz, Greg J
> Cc: sls-slp at mailman.ccsds.org; Takahiro Yamada; Ray,Timothy J.
> (GSFC-583.0); Jean-Luc.Gerner at esa.int;
> sls-slp-bounces at mailman.ccsds.org; gilles.moury at cnes.fr;
> Greenberg,Edward
> Subject: RE: [Sls-slp] JAXA RID against OID Frame
> 
> 
> 
> "Kazz, Greg J" <greg.j.kazz at jpl.nasa.gov> wrote on 03-03-2009
> 18:21:35:
> 
> > 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 
> >  
> 
> Greg, 
>      The Frame has a structure linked to the Virtual Channel and all
> frames on a VC have the secondary header (if this is used)
> independently they are OID or not. 
> Conversely the Space Packet has a structure linked to the APID and a
> mission implementing a Packet Secondary Header on Idle Packets would
> just be crazy. :-) In addition, I think that, being the idle APID
> fixed, there is no chance for having a Secondary header in an Idle
> Packet [this is TBC]. 
> 
> Comments/confirmations are welcome. 
> 
> Ciao 
> 
> Gian Paolo
> The information contained in this E-Mail and any subsequent 
> correspondence is private and is intended solely for the intended 
> recipient(s).  The information in this communication may be 
> confidential and/or legally privileged.  Nothing in this e-mail is 
> intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
> subject to any other legally binding commitments, unless the e-mail 
> contains an express statement to the contrary or incorporates a formal
> Purchase Order.
> 
> For those other than the recipient any disclosure, copying, 
> distribution, or any action taken or omitted to be taken in reliance 
> on such information is prohibited and may be unlawful.
> 
> Emails and other electronic communication with QinetiQ may be 
> monitored and recorded for business purposes including security,
> audit 
> and archival purposes.  Any response to this email indicates consent 
> to this.
> 
> Telephone calls to QinetiQ may be monitored or recorded for quality 
> control, security and other business purposes.
> 
> QinetiQ Limited
> Registered in England & Wales: Company Number:3796233
> Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
> Trading address: Cody Technology Park, Cody Building, Ively Road,
> Farnborough, Hampshire, GU14 0LX, United Kingdom 
> http://www.qinetiq.com/home/notices/legal.html
> <http://www.QinetiQ.com/home/legal.html> 
> 
> 
> 
> 
>  
> 
> 
> _______________________________________________
> Sls-slp mailing list
> Sls-slp at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sls-slp





More information about the SLS-SLP mailing list