[Sls-slp] JAXA RID against OID Frame

Cosby Matthew MCOSBY at qinetiq.com
Wed Mar 4 09:59:21 UTC 2009


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 

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] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20090304/e137029e/attachment.html>


More information about the SLS-SLP mailing list