<!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.2668" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<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></BODY></HTML>