<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian J. Hooke wrote:
<blockquote
cite="mid6.2.1.2.2.20050907120144.029cb8a0@mail.jpl.nasa.gov"
type="cite"><font color="#0000ff">At 01:40 PM 9/6/2005, Keith Hogie
wrote:<br>
</font>
<blockquote type="cite" class="cite" cite=""><font color="#0000ff">
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?</font></blockquote>
<br>
Aren't the Lunar missions supposed to be "training" for going
to Mars? For critical emergency commanding operations, shouldn't we be
developing a robust, unified, reliable, tested system that works
wherever
you go?<br>
<br>
</blockquote>
<br>
For emergency commanding I don't see any difference between Cislunar
or Deep Space. In both cases the solution is to send a string of bits
that gets decoded by hardware and do not need any protocol. The
critical hardware commands are their own frame sync, authentication,
and command all packed into a highly unique string of bits. Most
hardware decoders pick off the bits they are looking at directly from
the receiver and don't involve any flight software. This means that
there is no complex packet processing and the hardware is just looking
for particular sequence of bits. The length of this sequence is not a
function of any CCSDS or IP headers. Getting the command to the
spacecraft just requires radiating the proper string of bits. The
length of the hardware command is just a function of how many bits you
think you need to make sure your command doesn't occur in normal data
transfers. <br>
<br>
My main concern is for all the other operational modes there is a very
large disconnect between things that will work in a Cislunar
environment and a long haul link to Mars. If you consider the
following round trip times (RTT):<br>
<br>
0000.1 sec - Interaction between rovers, landers, (e.g. local
environment)<br>
0000.1 sec - Low-Earth orbit ( a few hundred kilometers one-way)<br>
0000.1 sec - Low-Lunar orbit ( a few hundred kilometers one-way)<br>
0000.1 sec - Low-Mars orbit ( a few hundred kilometers one-way)<br>
0000.5 sec - Earth geosync orbit (36,000 kilometers one-way)<br>
0002.5 sec - Earth-to-Moon (384,000 kilometers one-way)<br>
0010.0 sec - Earth to L1 or L2 (1,500,000 kilometers one-way)<br>
------------------Limit of Cislunar domain<br>
0366.0 sec - Earth to Mars (closest = 55.000.000 kilometers one-way, 6
minute, RTT)<br>
2673.0 sec - Earth to Mars (farthest = 401,000,000 kilometers one-way,
45 minute RTT)<br>
<br>
When you look at distances like these there is a huge break between
Cislunar ones and Mars. In the Cislunar area it is actually possible
to do interactive things like interactive audio, video, and data
access. You can consider security protocols that negotiate security
details. At L1 and L2 things get a bit uncomfortable at 10 seconds RTT
but that is still manageable. At Lunar distances you can do most
anything you do on Earth. A 2.5 second delay is a bit long for some
interactive operations but it is not really any longer than what
happens when you surf the open Internet and hit a bit of congestion.
The main point is that out to L1 and L2 you can actually do interactive
operations This also applies to systems on Mars and orbiting around
Mars. <br>
<br>
However, when you move to the long haul link between Earth and Mars,
the RTT jumps up to over 100 or 1,000 times that of the Earth and
Moon. With a 6 to 45 minute RTT, you can't carry on an interactive
voice or video conversation and lots of interactive data access just
doesn't work. On a Earth-to-Mars link you are forced to shift to an
operations concept of two one-way links. Operations must shift into
email-like file store-and-forward or one-way streaming of data. <br>
<br>
So I don't see any real problem with using the same hardware
commanding solution in Cislunar or Earth-to-Mars scenarios. Some file
store-and-forward and one-way streaming operations will also work for
both environments. Of course any acknowledgments on the file-store-and
forward will take lots longer. <br>
<br>
My concern is that other there are lots of protocols and applications
that will work fine in an interactive Cislunar environment but just
don't work for Earth-to-Mars. We don't want to limit our Cislunar
solutions to only those that will also work for Earth-to-Mars. I think
we need to develop our Cislunar solutions and then see if any of them
will also work in a Earth-to-Mars scenario. <br>
<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>
</body>
</html>