From edward.greenberg at jpl.nasa.gov Mon Jun 1 16:07:23 2009 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward) Date: Mon, 1 Jun 2009 09:07:23 -0700 Subject: [Sls-slp] CNES use of secondary header in frames Message-ID: Gilles, At the last meeting you stated that CNES places time in the secondary header of TM frames. I was wondering if you could elaborate on the rationale. Is it because you are using TM frames and the sequence count is inadequate for playback of high rate data or what specifically is the issue? Would the use of AOS frames change the need or would you still need a secondary header if you used AOS frames? I have been examining the use of AOS frames for Constellation and have found that the insert zone is useful for low rate AOS links but is a constraint for higher rate links which could benefit from a signaled secondary header. The use of a secondary header would also allow multiple Master Channels to share a physical channel without the insert constraint. I am interested in proposing that the AOS frame specification should be amended to allow a signaled secondary header. This would facilitate the use of a security header and the periodic insertion of a secondary header to carry voice codec segments. Secondary headers could easily replace the insert zone but extracting the insert zone capability at this time is premature and unnecessary since it is a managed field and it could easily be managed out of use. From greg.j.kazz at jpl.nasa.gov Mon Jun 1 17:53:11 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Mon, 1 Jun 2009 10:53:11 -0700 Subject: [Sls-slp] Performance Question concerning ESA proposed TC # retransmit parameter Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A376B28F@ALTPHYEMBEVSP10.RES.AD.JPL> Marjorie/G.P. ** I haven't heard from you regarding this issue below, so I thought I would try again to get your thoughts on this - thanks - Greg ** The following performance question and use case question has come up concerning the proposed ESA TC # retransmissions parameter: 1) Performance: Has there been any mathematical modeling to help determine what the expected increase in throughput that will likely be for various repeat/re-trans counts over the TC Space Link ? Could it have a significant link-margin consideration as well? 2) Use Case: Also would the number of retransmissions parameter set to greater than one be envisioned for any non-link layer driven scenarios? For example, I think it might be interesting to consider what role this plays in a space internetworking environment. Presumably this would just be in the link level set of services ... but maybe you want to make sure a key routing table arrives at a particular spacecraft? Would we ever consider that the spacecraft would implement this between themselves ? thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Jun 4 22:37:49 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Thu, 4 Jun 2009 15:37:49 -0700 Subject: [Sls-slp] Greg Kazz comments to NASA actions on Prox-1 C&S sublayer specification 5-year Review Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A3951CFE@ALTPHYEMBEVSP10.RES.AD.JPL> All, Please see attached my comments in line within the draft document, started by Gian-Paolo in Colorado Springs. I have also posted this document in the CWE as: http://cwe.ccsds.org/sls/docs/Forms/AllItems.aspx?RootFolder=%2fsls%2fdocs%2fSLS%2dSLP%2fDraft%20Documents&FolderCTID=&View=%7b16ACDA38%2dFFA3%2d4657%2d8F27%2dB166C23C24A2%7d Your comments are most welcome. P.S. G.P., I agreed with most of your comments that you documented however, there are a few that I have a problem with - mostly in Annex B. best regards Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CCSDS-211 2-B-1(Prox1 CandSL) CRC Pink 0 E_gjk.doc Type: application/msword Size: 690176 bytes Desc: CCSDS-211 2-B-1(Prox1 CandSL) CRC Pink 0 E_gjk.doc URL: From MCOSBY at qinetiq.com Fri Jun 12 13:58:04 2009 From: MCOSBY at qinetiq.com (Cosby Matthew) Date: Fri, 12 Jun 2009 14:58:04 +0100 Subject: [Sls-slp] 'OID' Frame Edits Message-ID: All, I have made the edits to the TM & AOS Blue Books as a result of the Space Link Protocols working group meeting. Changes to the TM specification: I have also modified the note in 4.1.4.6 to ensure the OID is consistently "Only Idle Data in its Data Field" in the document. From: 1 OID (Only Idle Data in the data field of the transfer frame) Frame - Transfer Frame in which the Frame data field contains Idle data. However, the transfer frame secondary header or Operational Control Field potentially contains valid data depending upon the Virtual Channel ID. To: 1 OID (Only Idle Data in its Data Field) Frame - Transfer Frame in which the Frame data field contains Idle data. However, the transfer frame secondary header or Operational Control Field potentially contains valid data depending upon the Virtual Channel ID. With the addition of the following in the acronym list: OID Only Idle Data in its Data Field Changes to the AOS specification: From: OID Only Idle Data To: OID Only Idle Data in its Data Field Even though OID is mentioned many times, it is only spelt out when first used. However it is explained in 4.1.4.1.5 and this section is referenced as few more times when OID is mentioned. I have put the Berlin and Colorado Springs modified documents on the CWE here: CWE - OID Work Please can the group take a look to see if these changes are suitable. Can I ask for comments by 26th June and copy Greg Kazz on any emails as I may be on leave as my baby is due tomorrow. If there are no comments, by this date, I will advise Tom Gannett to publish the books. Regards Matt. Matthew Cosby QinetiQ Space 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. 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: From greg.j.kazz at jpl.nasa.gov Wed Jun 17 18:33:49 2009 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J) Date: Wed, 17 Jun 2009 11:33:49 -0700 Subject: [Sls-slp] Proposal to unify TM & AOS Insert Zone and Secondary Header Usage Message-ID: <02D130BD9C29BB4AAD59B77342F7E25F45A3AE49F0@ALTPHYEMBEVSP10.RES.AD.JPL> Dear SLS-SLP and SLS-SEA-DLS WG members, We would like to get your feedback on the following attached proposal to unify the concepts of Insert Zone and Secondary Header in AOS and TM. The rationale for this proposal stems from the ongoing work within the SLS-SEA-DLS WG on defining Secondary Headers for Security and examination of use of Voice for Real-Time communications over space links. It turns out that by considering both of these cases and looking at mission's previous usage and design rationale for these fields, we believe it makes sense for both TM and AOS to include the same capabilities and services with respect to Secondary Headers and Insert Zones. At least one of the discussion points we would like to have within this community is how flexible we want to treat the Secondary Header in operations. The flexibility would allow for the Secondary Header to appear/or not appear on a frame by frame basis within a pass. Also the length of the Secondary Header could be dynamic meaning it could change length during a pass. These features would allow the insertion of Voice by means of a Secondary Header to be more efficient in a Push to Talk System which would be a benefit to the NASA Constellation Program. At this point, we invite you to examine the concepts expressed in the attachment and please inform us if you foresee any show stoppers here. thanks, Greg Kazz Chairman CCSDS SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Insert and SH (2)_gkeg1.doc Type: application/msword Size: 97280 bytes Desc: Insert and SH (2)_gkeg1.doc URL: