[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