<!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=731562213-24082005><FONT face=Arial color=#0000ff
size=2>Keith,</FONT></SPAN></DIV>
<DIV><SPAN class=731562213-24082005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=731562213-24082005><FONT face=Arial color=#0000ff size=2>Yes,
you are correct. The intent was to show how data would
be transmitted over a variety of link layers. My thoughts on Section
8 were that it primarily provide a small subset of examples in a
fairly established architecture so that readers could say "Ah, I see how it all
fits", thereby providing more context for the rest of the document and insight
into why this space network stuff is a good idea. I think this is
particularly useful for people (OK, at least me, anyway) that find it easier to
understand big pictures if they can see specific examples to go along with
it. Also, if it brings out more discussions on all of this to this list,
that's a nice additional benefit. My cop-out on avoiding a statement of
whether this is how things would really work was where I wrote that this was for
illustrative purposes only and not a recommendation.</FONT></SPAN></DIV>
<DIV><SPAN class=731562213-24082005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=731562213-24082005><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>Scott,Keith L.<BR><B>Sent:</B> Wednesday, August 24, 2005
9:21 AM<BR><B>To:</B> Keith Hogie;
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> RE: [Sis-csi] Cislunar Section
8<BR><BR></FONT></DIV>
<DIV dir=ltr align=left><SPAN class=297514412-24082005><FONT face=Arial
color=#0000ff size=2>For Chris's example I think AOS both ways is fine.
I suspect his intent was mainly to show heterogeneity of data link layers,
which is good. We could show AOS on the downlink and TC on the uplink,
but given the current directions within ESMD towards more symmetric
communications, AOS both ways may be more representative of how things will
look in the future. Considering that there are proposals to use link
encryption for security, I suspect that R/S decoding in space would not be
considered onerous.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=297514412-24082005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=297514412-24082005><FONT face=Arial
color=#0000ff size=2>When we get to the next level of detail,we will need to
worry about the data link layer mechanisms, as they have a bearing on the
ability to effect emergency operations (I'm thinking very low-level hardware
commands). At that point we will need to come up with a _small_ set of
Recommended approaches for data flows. I see this is populating the
general pipe diagrams we build in the Green book with specific
protocols.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=297514412-24082005><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN
class=297514412-24082005> <FONT
face=Arial color=#0000ff size=2>--keith</FONT></SPAN></DIV>
<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>Keith
Hogie<BR><B>Sent:</B> Wednesday, August 24, 2005 1:11 AM<BR><B>To:</B>
sis-csi@mailman.ccsds.org<BR><B>Subject:</B> Re: [Sis-csi] Cislunar Section
8<BR></FONT><BR></DIV>
<DIV></DIV>Adrian J. Hooke wrote:
<BLOCKQUOTE cite=mid6.2.1.2.2.20050823124439.031aa730@mail.jpl.nasa.gov
type="cite"><FONT color=#0000ff>At 12:17 PM 8/23/2005, Keith Hogie
wrote:<BR></FONT>
<BLOCKQUOTE class=cite cite="" type="cite"><FONT color=#0000ff>3 - The
protocol stack diagram is nice but I'm not sure about the AOS
boxes. Normally AOS is used for data coming down from
space.</FONT></BLOCKQUOTE><BR>Not so - the original architecture that was
developed for ISS was completely symmetric - the AOS frame was intended to
be used as either a unidirectional or a bi-directional space link
protocol. See <A
href="http://public.ccsds.org/publications/archive/701x0b3.pdf"
eudora="autourl">http://public.ccsds.org/publications/archive/701x0b3.pdf</A>
page 2-3.<BR></BLOCKQUOTE><BR><FONT color=#009900>I checked that document on
Tues. and saw that is said that AOS could be used either way. But the
comment was that missions have always used it on the downlink only. If
there are any missions using AOS in a two-way mode it would be good to know
about them. Are there any ground systems or satellite systems that can
use AOS on the uplink? <BR></FONT> <BR>
<BLOCKQUOTE cite=mid6.2.1.2.2.20050823124439.031aa730@mail.jpl.nasa.gov
type="cite">
<BLOCKQUOTE class=cite cite="" type="cite"><FONT color=#0000ff>It also
has Reed-Solomon coding on it. The diagram uses AOS in both
directions. Are we proposing the use of AOS and Reed-Solomon
coding both ways. This would require R/S encoders at ground
stations and decoders installed on spacecraft?</FONT></BLOCKQUOTE><BR>The
CCSDS space link protocols are cleanly layered: <A
href="http://public.ccsds.org/publications/archive/130x0g1.pdf"
eudora="autourl">http://public.ccsds.org/publications/archive/130x0g1.pdf<BR><BR></A>In
particular, the current AOS Space Link Protocol as defined in:<BR><A
href="http://public.ccsds.org/publications/archive/732x0b1.pdf"
eudora="autourl">http://public.ccsds.org/publications/archive/732x0b1.pdf</A>
is decoupled from its underlying coding layers.<BR><BR>The coding layer
that underlies AOS or conventional TM space links is defined in: <A
href="http://public.ccsds.org/publications/archive/131x0b1.pdf"
eudora="autourl">http://public.ccsds.org/publications/archive/131x0b1.pdf</A>
and note that it is NOT confined to R-S coding. It may be also expected to
evolve as new codes (such as LDPC) mature.<BR><BR></BLOCKQUOTE><FONT
color=#009900>All of those documents describe how the sync mark, R-S
codeblocks, and </FONT><FONT color=#009900>data link framing </FONT><FONT
color=#009900>are all directly related to each other. They all show
that the same sync information is used for both the FEC coding and data
framing. This is not the FEC and data link decoupling that has been
used in commercial satellite modems where the link coding is separate from
the data link framing. </FONT><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></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>