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

Tue, 15 Jul 2003 11:53:03 -0700

--=====================_708493890==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

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?

>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?

>** 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.

>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.

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

--=====================_708493890==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 10:12 AM 7/15/2003, Greg J Kazz wrote: 
<blockquote type=cite class=cite cite>** The rationale for this field is
to allow high rate mission to have a sequence counter that doesn't
rollover during a pass. </blockquote> 
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? 
<blockquote type=cite class=cite cite>Those
missions that do not require the extra field, simply set it to&nbsp; all
zeros, which they currently do today, because it is defined as a spare.
Those that do use it, will increment those bits accordingly.
**</blockquote> 
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? 
<blockquote type=cite class=cite cite>** AOS was
designed for SSF and ESA 's Hercules. Not a large contingent of users.
**</blockquote> 
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. 
<blockquote type=cite class=cite cite>This would
also benefit missions flying SSRs using AOS frame
retransmission.</blockquote> 
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
(<a href="http://www.ccsds.org/documents/701x0b3.pdf" eudora="autourl">http://www.ccsds.org/documents/701x0b3.pdf</a>)
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?&nbsp; 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. 
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 
</html>

--=====================_708493890==_.ALT--