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

[Greg J Kazz]

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