[Cesg-all] Re: Rick Schnurr's comments re: AOS Pink Sheets

[Richard G. Schnurr]

Hi Greg,

I have been following along and will now tiptoe into this conversation.

I think Adrian has a good point that the use of the new field should be 
indicated somehow.  If the main purpose of the field is to allow for 
retransmissions then it should be packaged with that services information 
and the indication would be that a reliable frame service is being 
used.  Clearly the ground should be able to ignore frame reliability and 
process the data normally if needed.

If regular missions needs this extension when not using reliable frames, 
not sure why since the ground equipment can keep track since everything 
should be in order, then the use of the new bits should be indicated.  I 
agree with Greg that the new bits can be ignored when not using reliable 
frames (since they are optional).  If I were a GSE designer I would ignore 
them all the time when reliability is not in use to simplify the 
software.  This gives more credence to Adrian's argument that the optional 
bits are only needed when one is using reliable frames requiring the ground 
system to watch for roll overs when frame reliability is not being used.

The issue for rollovers when using reliability is more complicated since a 
frame-id should not be re-used until it is released by the receiving 
authority (or possibly by some negative ack scheme).  IE the maximum number 
of id's available determines the max length of the reliability window.  I 
hope your reliability protocol doesn't have to guess about where the 
beginning/end of the window is.  Clearly the reliability software needs to 
know how big the window is and signalling the window size is a different 
problem since many missions might run out of frame buffers before it runs 
out of unique id's.

I will stop here because I have not studied the frame reliability protocol.

I am not in favor however of mandating the use of the extra three frame ID 
bits since we have existing missions that do not use them. (This is my 
opinion: if you argue the point I will talk to the flight types and get 
more input).

I think it makes sense to bundle this change with any other recommendation 
covering reliable frame processing since that is a new thing and we can 
implement it in a way that makes sense.  Personally, I am having trouble 
following all the your arguments without understanding the overall 
operation of reliable frames.  Leading credence to Adrian's point that the 
two changes should be bundled.

Please correct my thinking as required.

Rick





At 03:58 PM 7/15/2003, Greg J Kazz wrote:
>At 7/15/2003 11:53 AM, Adrian J. Hooke wrote:
>>At 10:12 AM 7/15/2003, Greg J Kazz wrote:
>>>** The rationale for this field is to allow high rate mission to have a 
>>>sequence counter that doesn't rollover during a pass.
>>
>>Any counter will roll over eventually - it depends on the frame length 
>>and the data rate. If I punched the buttons on my trusty Casio wrist 
>>communicator properly, a 2**27 counter rolls over in 3.8 hours if the 
>>frame length is 10K bits and the data rate is 100Mb/s. That's a data rate 
>>that we may see from Mars in the lifetime of this standard.
>>
>>Surely there are other ways to handle rollover. For instance, why not 
>>switch to another Virtual Channel when rollover occurs? You've got 64 of 
>>those buggers to use, and presumably right now most of them are going unused.
>>
>>And anyway, what's the problem if the counter *does* roll over? Don't we 
>>have other ground mechanisms to detect this?
>
>
>** It's a flight system issue. The flight system requires a simple method 
>for identifying AOS frames for retransmission. **
>
>
>>>Those missions that do not require the extra field, simply set it 
>>>to  all zeros, which they currently do today, because it is defined as a 
>>>spare. Those that do use it, will increment those bits accordingly. **
>>
>>But how does the receiver know whether this field is used or not? 
>>Whichever way you look at it, you're running a different protocol with a 
>>24-bit counter than you are with a 27-bit counter. Different protocols 
>>are normally signalled to the receiver. How is the signalling done in 
>>your proposal?
>
>
>** Ground operations could be managed if required for retransmission 
>support. **
>
>
>
>
>>>** AOS was designed for SSF and ESA 's Hercules. Not a large contingent 
>>>of users. **
>>
>>I don't understand this. Since it has an 8-bit SCID, the AOS frame can 
>>handle another 254 spacecraft before we run out of unique spacecraft 
>>names. AOS can certainly accommodate an order of magnitude more user 
>>spacecraft than anyone currently has on the drawing board. ** yes the 
>>capability is there, just pointing out that the user community for AOS 
>>today is rather small **
>>
>>>This would also benefit missions flying SSRs using AOS frame retransmission.
>>
>>No doubt. But then why don't you package this change as part of an 
>>omnibus proposal that adds the AOS retransmission procedures *and* the 
>>capability to handle higher data rates? And in the process, why don't you 
>>update the whole AOS recommendation 
>>(http://www.ccsds.org/documents/701x0b3.pdf) to reflect this omnibus 
>>change, including a complete re-write of para. 5.4.9.2.2 and the entire 
>>Section 6 -- which already contains an incomplete definition of a Space 
>>Link ARQ Procedure?  Otherwise it will surely be extremely confusing to a 
>>user to see two separate ARQ mechanisms in the specification, and no way 
>>to differentiate between them. ** Actually this book is dead and has been 
>>woefully out of date for a long time. Part of the problem is retiring the 
>>old AOS book and making changes to Yamada's restructured book from this 
>>point on. SLS-WG is working with Tom G. on how best to procede on this. **
>
>>  **
>>
>>Greg, I don't want to be a pill about this, but there is a lot at stake 
>>here in terms of controlling the quality of our products. If I am missing 
>>something, please correct me.
>>
>>///adrian
>
>
>_______________________________________________
>CESG-all mailing list
>CESG-all@mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/cesg-all

Richard G Schnurr Jr
Chief Architect
Electrical Systems Center
Applied Engineering and Technology Directorate
NASA GSFC Code 560.0
Greenbelt MD 20771

(301)-286-1852