<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></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 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></BODY></HTML>