[Sls-ocm] Help with OLSG Action Concerning Applicable CCSDS Protocols / Tranfer Frame vs. AOS Frame

[Edwards, Bernard L. (GSFC-5600)]

Dear Gian Paolo,

Thank you for your note.

I agree 100% with your statement:  "The services offered by the TM and AOS Space Data Link Protocols (and therefore by their Transfer Frames formats) are largely equivalent and share similar limitations. Therefore any limitation to constrain optical links to single frame format should have a very sound rationale."

I agree it is not critical that everybody use AOS and it is doubtful everybody will (as in the case of RF systems and interoperability).  However, that was NASA's "opening recommendation" going back to the OLSG.  ESA, TESAT, DLR, and NASA met today and we agree that it is not a necessity.  Thus I do agree that it is something that needs to be looked at by CCSDS and NASA's opening recommendation may be too restrictive!

Sincerely,
Bernie Edwards

From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Monday, March 11, 2013 11:00 AM
To: Edwards, Bernard L. (GSFC-5600)
Cc: sls-com at mailman.ccsds.org; sls-com-bounces at mailman.ccsds.org
Subject: Re: [Sls-ocm] Help with OLSG Action Concerning Applicable CCSDS Protocols / Tranfer Frame vs. AOS Frame

> As part of this action, NASA has proposed to the OLSG group that
> future optical communications links use the CCSDS standard AOS at
> the frame level.  That will ensure that all CCSDS protocols above
> AOS will be compatible with future optical communications links.
> This is what is currently being done on NASA's Laser Communications
> Relay Demonstration (LCRD) project in development.  If this is
> accepted by the group, then the group can focus on standards needed
> below the frame level.
>
Dear Bernie,
        I must say that I am a little puzzled by the NASA proposed approach.

CCSDS has developed four protocols for the Data Link Protocol Sublayer of the Data Link Layer:
a)TM Space Data Link Protocol
b)TC Space Data Link Protocol
c)AOS Space Data Link Protocol
d)Proximity-1 Space Link Protocol-Data Link Layer

The TM and AOS Space Data Link Protocols use fixed-length Transfer Frames to facilitate robust synchronization procedures over a noisy link, while the TC
Space Data Link Protocol and the Proximity-1 Space Link Protocol use variable-length Transfer Frames to facilitate reception of short messages with a short delay.

The services offered by the TM and AOS Space Data Link Protocols (and therefore by their Transfer Frames formats) are largely equivalent and share similar limitations. Therefore any limitation to constrain optical links to single frame format should have a very sound rationale.

Moreover, the Coding and Synchronization standards applied to the downlink are independent from the frame format used at the upper layer.
The only constraints applied are the fixed-length and the minimum/maximum) size of the frames provided.
Therefore I am really puzzled by an approach that would design the Data Link Coding & Sync Sublayer (for optical links) based on a single frame structure.
Note that this would not only be a limitation for the current CCSDS asset, but may even jeopardize further evolution of the Data Link Protocol Sublayer if its lower (sub)layer is too rigid.

To summarize, I find perfectly admissible that the NASA's Laser Communications Relay Demonstration (LCRD) project selects the AOS format, but I do not see enough element to justify this choice as the only allowed one.

Most likely this will be something to be investigated in CCSDS.

Best regards

Gian Paolo

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.



Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sls-com/attachments/20130311/50fff0a0/attachment.html