[Sis-csi] Cislunar Section 8

[Krupiarz, Christopher]

Keith,
 
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.
 
Chris

	-----Original Message-----
	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Scott,Keith L.
	Sent: Wednesday, August 24, 2005 9:21 AM
	To: Keith Hogie; sis-csi at mailman.ccsds.org
	Subject: RE: [Sis-csi] Cislunar Section 8
	
	
	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.
	 
	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.
	 
	        --keith

________________________________

		From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Keith Hogie
		Sent: Wednesday, August 24, 2005 1:11 AM
		To: sis-csi at mailman.ccsds.org
		Subject: Re: [Sis-csi] Cislunar Section 8
		
		
		Adrian J. Hooke wrote: 

			At 12:17 PM 8/23/2005, Keith Hogie wrote:
			

				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.


			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 http://public.ccsds.org/publications/archive/701x0b3.pdf
page 2-3.
			


		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?  
		 
		

				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?


			The CCSDS space link protocols are cleanly
layered: http://public.ccsds.org/publications/archive/130x0g1.pdf
			
			In particular, the current AOS Space Link
Protocol as defined in:
	
http://public.ccsds.org/publications/archive/732x0b1.pdf is decoupled
from its underlying coding layers.
			
			The coding layer that underlies AOS or
conventional TM space links is defined in:
http://public.ccsds.org/publications/archive/131x0b1.pdf 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.
			
			

		All of those documents describe how the sync mark, R-S
codeblocks, and data link framing 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.  
		
		-- 
	
----------------------------------------------------------------------
		  Keith Hogie                   e-mail:
Keith.Hogie at gsfc.nasa.gov
		  Computer Sciences Corp.       office: 301-794-2999
fax: 301-794-9480
		  7700 Hubble Dr.
		  Lanham-Seabrook, MD 20706  USA        301-286-3203 @
NASA/Goddard
	
---------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20050824/f2c2c780/attachment.htm