<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2>With the hardware command... I agree with Keith
S.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2>That being said, the hardware will simply match a bit
pattern. That could be an entire packet, or a part of a packet. The
hardware pattern detector does not care what comes before or after the command
sequence. So, you could either:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2>1. Send the HW command as the "payload" of a whole packet
in which case the bit pattern will match (throwing away the rest of the
packet). The problem here is that you will need to keep sending the whole
packet out, so you have more overhead to get into that small window while the
s/c is tumbling.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2>2. Or, In an emergeny, just transmit the HW command
sequence over and over (like Keith's example) and bypass all overhead and
formatting at the ground system (we're talking spacecraft emergency, here... not
prime ops) If the command receiver is designed not to interpret a packet
(and it should not have to be) then all that it needs to see is the command
sequence shifting by...</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=045382915-30092005><FONT face=Arial
color=#0000ff size=2>- Jason</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV align=left><FONT face=Arial
size=2>____________________________________________</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>"It's kind of fun to do the impossible."
- Walt Disney</FONT></DIV>
<DIV align=left><FONT face=Arial size=2></FONT> </DIV>
<DIV align=left><FONT face=Arial size=2>Jason A. Soloff</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Chief Systems Engineer</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Exploration Communication &
Navigation Systems</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Constellation Systems</FONT></DIV>
<DIV align=left><FONT face=Arial size=2></FONT> </DIV>
<DIV align=left><FONT face=Arial size=2>NASA / Goddard Space Flight
Center</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Code 567 / B19 / S046</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Greenbelt, MD 20771</FONT></DIV>
<DIV align=left><FONT face=Arial size=2></FONT> </DIV>
<DIV align=left><FONT face=Arial size=2>Phone: (301)286-1368</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Blackberry: (301)356-3708</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>Fax: (301)286-1750</FONT></DIV>
<DIV align=left><FONT face=Arial size=2>E-Mail: <A
href="mailto:Jason.A.Soloff@nasa.gov">Jason.A.Soloff@nasa.gov</A></FONT></DIV>
<DIV align=left><FONT face=Arial size=2></FONT> </DIV>
<DIV> </DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Scott, Keith
L.<BR><B>Sent:</B> Friday, September 30, 2005 10:13 AM<BR><B>To:</B> Krupiarz,
Christopher; Keith Hogie; sis-csi@mailman.ccsds.org<BR><B>Subject:</B> RE:
[Sis-csi] IP Header Compression<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=590480214-30092005><FONT face=Arial
color=#0000ff size=2>While we're pushing to get as much data as possible over
IP, there will probably still be for a long time some data that wants to sit
directly on top of the space link. These could be legacy applications
that run directly over space data packets and don't want to move (and know
that they will not need to go multi-hop), or 'special' commands that just
can't deal with the overhead of IP. The canonical example of the latter
is the 'tumbling spacecraft' problem, where the spacecraft is spinning and it
won't hold still long enough to point its antenna at Earth to receive the
'stop that' command. This actually occurred, and the saving grace was
being able to transmit (over and over and over) a very short 'safe the
spacecraft' command that was hardware decoded. While you're right that
one might look for a particular bit stream that happens to be an IP packet in
the hardware decoder, there might be advantage to being able to do it in fewer
bits. Then again, there's security, which would seem to be sort of
mutually exclusive with 'short command that causes the spacecraft to do
something sort of drastic (like safe mode).'</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=590480214-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=590480214-30092005><FONT face=Arial
color=#0000ff size=2>All that said, the way I can see bit rate playing into
this is that we're really interested in how many bits are needed for emergency
command, and how many bits we can inject into the spacecraft before it goes
off and does something else (spins, reboots again, ...). We may need to
have two answers, one for people who absolutely require security (may as well
use IP and IPSEC here) and one for people who don't (allows very short
commands but requires a direct data link connection to the thing doing the
resetting)?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=590480214-30092005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN
class=590480214-30092005> <FONT
face=Arial color=#0000ff size=2>--keith</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Krupiarz,
Christopher<BR><B>Sent:</B> Wednesday, September 07, 2005 11:12
AM<BR><B>To:</B> Keith Hogie; sis-csi@mailman.ccsds.org<BR><B>Subject:</B>
RE: [Sis-csi] IP Header Compression<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2>Keith,</FONT></SPAN></DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff size=2>I
do not have extensive R/F knowledge and, therefore, can't really give you an
answer regarding what we would see at the Moon. However, part of
the Cislunar charter is to extend, where possible, the architecture to Mars
where missions currently do have that low of a bit rate. The answer
may be whether this falls into the "where possible" category or not and your
concern is very valid. If there is someone with greater R/F experience
than I have on this list who could chime in (in particular,thoughts on rates
on the Moon), that would be very helpful.</FONT></SPAN></DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff size=2>As
for your second point, I'm not sure I follow. Could you elaborate a
bit on how you would see commanding done in an emergency situation without
using an IP packet? I probably got lost along the way, but I made the
assumption that in this architecture all packets that a spacecraft received
would be an IP packet. The hardware decode command (I think equivalent
to our critical commands here) would just be a bit string, but it would
still be in an IP packet.</FONT></SPAN></DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2>BTW, I'll have to double check (well, I guess this would be triple
check now ;), but I may have swapped emergency commanding with emergency
telemetry rates. Emergency commanding is ~7.8 bps versus emergency
telemetry at 10 bps.</FONT></SPAN></DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=658080714-07092005><FONT face=Arial color=#0000ff
size=2>Chris</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
sis-csi-bounces@mailman.ccsds.org
[mailto:sis-csi-bounces@mailman.ccsds.org] <B>On Behalf Of </B>Keith
Hogie<BR><B>Sent:</B> Tuesday, September 06, 2005 4:40 PM<BR><B>To:</B>
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-csi] IP Header
Compression<BR><BR></FONT></DIV>Chris,<BR><BR> 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. <BR><BR> 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?<BR><BR> 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.<BR><BR>Keith
Hogie<BR><BR>Krupiarz, Christopher wrote:<BR>
<BLOCKQUOTE
cite=mid7E1D82EADE01E542AA57E940D38FD78D043958C3@aplesliberty.dom1.jhuapl.edu
type="cite">
<META content="MS Exchange Server version 6.5.7232.68" name=Generator><!-- Converted from text/rtf format -->
<P><FONT face=Arial size=2>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).</FONT></P>
<P><FONT face=Arial size=2>Chris</FONT> </P><PRE wrap=""><HR width="90%" SIZE=4>
_______________________________________________
Sis-CSI mailing list
<A class=moz-txt-link-abbreviated href="mailto:Sis-CSI@mailman.ccsds.org">Sis-CSI@mailman.ccsds.org</A>
<A class=moz-txt-link-freetext href="http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi">http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi</A>
</PRE></BLOCKQUOTE><PRE class=moz-signature cols="72">----------------------------------------------------------------------
Keith Hogie e-mail: <A class=moz-txt-link-abbreviated href="mailto:Keith.Hogie@gsfc.nasa.gov">Keith.Hogie@gsfc.nasa.gov</A>
Computer Sciences Corp. office: 301-794-2999 fax: 301-794-9480
7700 Hubble Dr.
Lanham-Seabrook, MD 20706 USA 301-286-3203 @ NASA/Goddard
---------------------------------------------------------------------- </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>