[Sis-csi] IP Header Compression

[Greg Kazz]

All,

JPL spacecraft handle this problem similarly using the Virtual Channel ID 
(VCID) within the frame layer instead of MAPs. If Hardware commands are 
sent, they are placed at the beginning of the data field of a TC frame and 
interpreted by the Hardware Command Decoder (HCD) which by-passes flight 
software.

Greg
At 08:32 AM 9/7/2005, Matthew Cosby wrote:
>Dave / Howie / John,
>
>In Europe we get around this problem with a Command Pulse Distribution 
>Unit (CPDU) installed in the Packet Telecommand Decoder (PTD -  "hunk of 
>hardware that doesn't rely on the correct operation of the flight 
>computer" ). This hardware commanding utilises the Multiplexed Access 
>Point (MAP) identifiers in the segmentation layer of the Telecommand Stack.
>
>I have attached a data sheet of PTD for you read - Section 4.5. The upshot 
>of it is you can send a command to the PTD (within the communications 
>system) that can toggle up to 256 lines, for resetting the flight 
>computer, switching antenna, etc without needing to worry about the high 
>level stuff on top.
>
>We (Space Link Guys) are currently designing a similar, but simpler 
>interface for the Prox-1 links.
>
>Cheers
>
>Matt.
>
>
>
>At 16:01 07/09/2005, Dave Israel wrote:
>>The GPM folks had worked out a solution to this that they were 
>>comfortable with a few years ago.  I believe the emergency commands were 
>>the right combination of information in the IP header itself.  We at GSFC 
>>should be able to get what they planned to do and provide it to the WG to 
>>discuss further.
>>
>>Dave
>>
>>At 10:49 AM 9/7/2005, Howard Weiss wrote:
>>>John,
>>>
>>>Exactly - and also that the short command be consumed by a hunk of 
>>>hardware that doesn't rely on the correct operation of the flight 
>>>computer, its software, and its protocol stack - all of which might be 
>>>slightly brain-damaged and incapable of acting on the emergency command.
>>>
>>>Howie
>>>
>>>John Pietras wrote:
>>>>In the tumbling S/C scenario, a major concern was that the commands be 
>>>>short enough to allow a complete one to be seen while the S/C is 
>>>>"looking" in the direction of the antenna. This is where the difference 
>>>>in overhead between a CCSDS packet and an IP header might make or break 
>>>>the recovery effort.
>>>>
>>>>John Pietras
>>>>
>>>>
>>>>From: 
>>>><mailto:sis-csi-bounces at mailman.ccsds.org>sis-csi-bounces at mailman.ccsds. 
>>>>org [ mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Howard Weiss
>>>>Sent: Wednesday, September 07, 2005 9:00 AM
>>>>To: Keith Hogie
>>>>Cc: <mailto:sis-csi at mailman.ccsds.org>sis-csi at mailman.ccsds.org
>>>>Subject: Re: [Sis-csi] IP Header Compression
>>>>
>>>>Keith,
>>>>
>>>>When we first started working on SCPS (way, way, way back in what seems 
>>>>now like the stone ages) we were faced with this same dilemma - how to 
>>>>allow emergency mode messages in w/o having to deal with the on-board 
>>>>computer and the protocol stack.  Honestly, this was something we never 
>>>>looked at when we started researching the ways in which upper layer 
>>>>protocols would be used in a spacecraft.  I guess we were all network 
>>>>weenies who figured that the CD&H would be just like an IP router (or 
>>>>just an IP router if IP were used vs. NP) and all would be good.  So, 
>>>>the idea for hardware command decoders being able to handle 
>>>>emergency-mode commanding (e.g., reset, safe-mode) came up to bite us 
>>>>back in the mid-90s because of the kinds of heroic efforts that the UKs 
>>>>STRV team used to recover a tumbling micro-sat by constantly shooting 
>>>>CCSDS telecommands at it to cause it to go into safe-mode.  We realized 
>>>>at that time that if uppler layer protcols were to be used aboard 
>>>>spacecraft that the command decoders would have to be able to parse and 
>>>>handle these types of emergency mode commands outside of the protocol 
>>>>stack.  Security, however becomes paramount at the space link if such 
>>>>hardware command decoding is employed.
>>>>
>>>>Howie Weiss
>>>>
>>>>Keith Hogie wrote:
>>>>Chris,
>>>>
>>>>   I agree we need to consider issues with small packets and low rates, 
>>>> but how low do we need to go.  In all of the missions I have seen (non 
>>>> deep space), the lowest data rates are 125 bps.  This is over an order 
>>>> of magnitude difference from your 10 bps.
>>>>
>>>>   For the Cislunar environment, we need to figure out what some of our 
>>>> limits are.  Do we really want to burden the Cislunar design with 
>>>> issues that only relate to Deep Space?
>>>>
>>>>   Also, for hardware decode commands like hardware reset, I'm not sure 
>>>> if packet sizes or IP or CCSDS headers really matter.  Isn't a 
>>>> hardware decode command just a string of bits (hopefully long enough 
>>>> to be unique) that get grabbed by hardware without any special packet 
>>>> knowledge.  That would mean that this bit string can be carried inside 
>>>> any packet and the only length that matters is the length of the 
>>>> hardware command bitstring.
>>>>
>>>>Keith Hogie
>>>>
>>>>Krupiarz, Christopher wrote:
>>>>
>>>>I was curious about thoughts as to if and where we would address IP 
>>>>header compression in the Green Book.  On some our missions (and I 
>>>>think this is typical at least in deep space), if we have a reset of 
>>>>the system, the spacecraft may come up in an emergency mode of 
>>>>receiving 10 bps.  Hence, every bit is quite valuable at this 
>>>>point.  With a CCSDS header, we're looking at 6 bytes (plus a couple of 
>>>>bytes if a secondary header is used).  If we move to IPv6, this becomes 
>>>>40.  At 10 bps, that's an additional uplink time of 25-26 seconds 
>>>>before a command can be received which is long enough to envision some 
>>>>nightmare scenarios.  Clearly IP header compression would alleviate 
>>>>this concern but I'm not sure where it fits or if it is needed in this 
>>>>doc (I hope I didn't miss it somewhere).
>>>>
>>>>Chris
>>_______________________________________________
>>Sis-CSI mailing list
>>Sis-CSI at mailman.ccsds.org
>>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
>----------
>Note:
>The information contained in this email and any subsequent correspondence 
>is private and is intended solely for the intended recipient(s). For those 
>other than the intended recipient(s) any disclosure, copying, 
>distribution, or any action taken or omitted to be taken in reliance on 
>such information is prohibited and may be unlawful.
>
>----------
>
>_______________________________________________
>Sis-CSI mailing list
>Sis-CSI at mailman.ccsds.org
>http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi